受限环境的最低要求
验证系统的性能
配置 Swap
优化 Puma
优化 Sidekiq
优化 Gitaly
禁用监控
配置 GitLab 如何处理内存
禁用额外的应用程序内监控
包含所有更改的配置
性能结果

在内存受限的环境中运行

在启用所有功能的情况下运行时，极狐GitLab 需要大量内存。有一些用例，例如在不需要所有功能的较小安装上运行极狐GitLab。例子包括：

运行极狐GitLab 供个人使用或非常小的团队使用。
使用云提供商上的小实例来节省成本。
使用资源受限的设备，如 Raspberry PI。

通过一些调整，GitLab 可以在比最低要求中描述的规格低得多的规格下舒适地运行。

以下部分包含允许在不满足最低要求的环境中运行的建议。虽然大多数部件在这些设置到位后应该可以正常工作，但您可能会遇到产品功能和性能的意外降级。您应该能够与最多 5 个开发人员一起运行 GitLab，并且单个 Git 项目不超过 100MB。

受限环境的最低要求

可以运行 GitLab 的最低预期规格是：

基于 Linux 的系统（最好基于 Debian 或基于 RedHat）
4 个 ARM7/ARM64 CPU 内核或 1 个 AMD64 架构 CPU 内核
最低 2GB RAM + 1GB SWAP，最佳为 2.5GB RAM + 1GB SWAP
20GB 可用存储空间
具有良好随机 I/O 性能且具有优先顺序的存储：

以上列表中，CPU 的单核性能和存储的随机 I/O 性能影响最大。存储尤其重要，因为在受限环境中，我们预计会发生一定量的内存交换，这会给使用过的磁盘带来更大的压力。小平台性能有限的一个常见问题是磁盘存储速度非常慢，这会导致系统范围的瓶颈。

使用这些最小设置，系统应该在常规操作期间使用 swap。由于并非所有组件都同时使用，因此它应该提供可接受的性能。

验证系统的性能

有许多工具可以让您验证基于 Linux 的系统的性能。可以帮助检查系统性能的项目之一是 sbc-bench。它描述了系统测试的所有注意事项以及不同行为对系统性能的影响，这在嵌入式系统中运行 GitLab 时尤其重要。它可以用作一种验证系统性能是否足以在受限环境中运行 GitLab 的方法。

这些系统提供足够的性能来运行 GitLab 的小型安装：

配置 Swap

在安装 GitLab 之前，您需要配置 swap。Swap 是磁盘上的专用空间，在物理 RAM 已满时使用。当 Linux 系统耗尽 RAM 时，非活动页面将从 RAM 移动到交换空间。

交换使用通常被认为是一个问题，因为它会增加延迟。但是，由于 GitLab 的运作方式，分配的大部分内存不会被频繁访问。使用 swap 允许应用程序正常运行和运行，并且只偶尔使用 swap。

一般准则是将交换配置为可用内存的 50% 左右。对于内存受限的环境，建议为系统配置至少 1GB 的交换空间。有许多关于如何做到这一点的指南：

配置后，您应该验证交换是否已正确启用：

free -h
              total        used        free      shared  buff/cache   available
Mem:          1.9Gi       115Mi       1.4Gi       0.0Ki       475Mi       1.6Gi
Swap:         1.0Gi          0B       1.0Gi

您还可以通过调整 /proc/sys/vm/swappiness 来配置系统使用 swap 空间的频率。 Swappiness 范围在 0 和 100 之间。默认值为 60。较低的值降低了 Linux 对释放匿名内存页面并将它们写入交换的偏好，但它增加了对文件支持页面执行相同操作的偏好：

在当前会话中配置它：
```
sudo sysctl vm.swappiness=10
```
编辑 /etc/sysctl.conf 使其永久化：
```
vm.swappiness=10
```

优化 Puma

这是一项实验性 Alpha 功能，如有更改，恕不另行通知。该功能尚未准备好用于生产用途。如果您想使用此功能，我们建议您先使用非生产数据进行测试。

默认情况下，GitLab 使用旨在处理许多并发连接的配置运行。

对于不需要高吞吐量的小型安装，考虑禁用 Puma 集群模式。结果，只有一个 Puma 进程可以为应用程序提供服务。

在 /etc/gitlab/gitlab.rb 中：

puma['worker_processes'] = 0

我们观察到以这种方式配置 Puma 内存使用量减少了 100-400MB。

优化 Sidekiq

Sidekiq 是一个后台处理守护进程。默认情况下使用 GitLab 配置时，它以 50 的高并发模式运行。这确实会影响它在给定时间可以分配多少内存。建议将其配置为使用显着较小的 5 或 10（首选）值。

在 /etc/gitlab/gitlab.rb 中：

sidekiq['max_concurrency'] = 10

优化 Gitaly

Gitaly 是一种存储服务，允许高效访问基于 Git 的存储库。建议配置 Gitaly 强制执行的最大并发和内存限制。

在 /etc/gitlab/gitlab.rb 中：

gitaly['ruby_max_rss'] = 200_000_000
gitaly['concurrency'] = [
  {
    'rpc' => "/gitaly.SmartHTTPService/PostReceivePack",
    'max_per_repo' => 3
  }, {
    'rpc' => "/gitaly.SSHService/SSHUploadPack",
    'max_per_repo' => 3
  }
]

gitaly['cgroups_count'] = 2
gitaly['cgroups_mountpoint'] = '/sys/fs/cgroup'
gitaly['cgroups_hierarchy_root'] = 'gitaly'
gitaly['cgroups_memory_enabled'] = true
gitaly['cgroups_memory_limit'] = 500000
gitaly['cgroups_cpu_enabled'] = true
gitaly['cgroups_cpu_shares'] = 512

gitaly['env'] = {
  'GITALY_COMMAND_SPAWN_MAX_PARALLEL' => '2'
}

禁用监控

GitLab 默认启用所有服务，无需任何额外配置即可提供完整的 DevOps 解决方案。一些默认服务，如监控，对于 GitLab 的运行来说不是必不可少的，可以禁用以节省内存。

在 /etc/gitlab/gitlab.rb 中：

prometheus_monitoring['enable'] = false

我们观察到以这种方式配置 GitLab 减少了 200MB 的内存使用量。

配置 GitLab 如何处理内存

GitLab 由许多组件（用 Ruby 和 Go 编写）组成，其中 GitLab Rails 是最大的一个，占用的内存最多。

GitLab Rails 使用 jemalloc 作为内存分配器。jemalloc 以更大的块预分配内存，这些块也被保留更长的时间以提高性能。以牺牲一些性能为代价，您可以将 GitLab 配置为在不再需要内存后立即释放内存，而不是将其保留更长的时间。

在 /etc/gitlab/gitlab.rb 中：

gitlab_rails['env'] = {
  'MALLOC_CONF' => 'dirty_decay_ms:1000,muzzy_decay_ms:1000'
}

gitaly['env'] = {
  'LD_PRELOAD' => '/opt/gitlab/embedded/lib/libjemalloc.so',
  'MALLOC_CONF' => 'dirty_decay_ms:1000,muzzy_decay_ms:1000'
}

我们在应用程序执行期间观察到更稳定的内存使用情况。

禁用额外的应用程序内监控

GitLab 使用内部数据结构来衡量自身的不同方面。如果禁用监控，则不再需要这些功能。

要禁用这些功能，您需要转到 GitLab 的管理中心并禁用 Prometheus Metrics 功能：

进入 GitLab 网页界面。
在顶部栏上，选择 菜单 > 管理员。
在左侧边栏上，选择 设置 > 指标与分析。
展开 指标 - Prometheus。
禁用 启用 Prometheus 指标。
选择 保存更改。

包含所有更改的配置

如果您应用到目前为止描述的所有内容，您的 /etc/gitlab/gitlab.rb 文件应该包含以下配置：

puma['worker_processes'] = 0

sidekiq['max_concurrency'] = 10

prometheus_monitoring['enable'] = false

gitlab_rails['env'] = {
  'MALLOC_CONF' => 'dirty_decay_ms:1000,muzzy_decay_ms:1000'
}

gitaly['cgroups_count'] = 2
gitaly['cgroups_mountpoint'] = '/sys/fs/cgroup'
gitaly['cgroups_hierarchy_root'] = 'gitaly'
gitaly['cgroups_memory_enabled'] = true
gitaly['cgroups_memory_limit'] = 500000
gitaly['cgroups_cpu_enabled'] = true
gitaly['cgroups_cpu_shares'] = 512

gitaly['concurrency'] = [
  {
    'rpc' => "/gitaly.SmartHTTPService/PostReceivePack",
    'max_per_repo' => 3
  }, {
    'rpc' => "/gitaly.SSHService/SSHUploadPack",
    'max_per_repo' => 3
  }
]
gitaly['env'] = {
  'LD_PRELOAD' => '/opt/gitlab/embedded/lib/libjemalloc.so',
  'MALLOC_CONF' => 'dirty_decay_ms:1000,muzzy_decay_ms:1000',
  'GITALY_COMMAND_SPAWN_MAX_PARALLEL' => '2'
}

进行所有这些更改后，重新配置极狐GitLab 以使用新设置：
```
sudo gitlab-ctl reconfigure
```
此操作可能需要一段时间，因为到目前为止，GitLab 无法使用内存保守设置。

性能结果

应用上述配置后，您可以预期以下内存使用情况：

              total        used        free      shared  buff/cache   available
Mem:          1.9Gi       1.7Gi       151Mi        31Mi       132Mi       102Mi
Swap:         1.0Gi       153Mi       870Mi