☰

Gitlab：ruby“bundle”进程的内存消耗极高

tag-icon • tag-icon linux ruby gitlab ubuntu-16.04
Gitlab：ruby“bundle”进程的内存消耗极高

我在小型 Ubuntu LTS 16.04 上运行 Gitlab 安装时遇到问题。我必须指出，我对 Linux 或 Gitlab 没有太多经验。

我的 Gitlab 安装了一些个人项目（只有 4 个），运行正常，但推送速度极慢，有时会失败。此外，访问 Web 界面的速度也非常慢。我检查了服务器，发现总内存的使用率高达 96%。罪魁祸首似乎是捆绑进程。

top - 00:15:30 up 59 days, 16:17,  1 user,  load average: 0.00, 0.01, 0.09
Tasks: 160 total,   1 running, 159 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.5 us,  0.2 sy,  0.0 ni, 99.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem : 72.4/2048272  [|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||                           ]
KiB Swap:  0.0/0        [                                                                                                    ]

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 8760 git       20   0  648908 412768  14700 S   0.7 20.2   0:30.58 bundle
 8799 git       20   0  513748 302632  14300 S   0.0 14.8   0:20.02 bundle
 8833 git       20   0  513748 293028   4696 S   0.0 14.3   0:00.03 bundle
 8839 git       20   0  513748 292904   4572 S   0.0 14.3   0:00.02 bundle
 8836 git       20   0  513748 292840   4508 S   0.3 14.3   0:00.04 bundle
11792 mysql     20   0 1567168 158296      0 S   0.0  7.7   5:01.31 mysqld
32688 root      20   0 11.279g  99476   1164 S   0.0  4.9   1:21.06 dotnet
 8092 gitlab-+  20   0  576816  39616  39020 S   0.0  1.9   0:00.10 postgres
 8854 gitlab-+  20   0  595572  15004  10524 S   0.0  0.7   0:00.09 postgres
 8075 git       20   0  128348  14896   7680 S   0.0  0.7   0:00.07 gitlab-workhors
 8830 gitlab-+  20   0  592816  12196   9780 S   0.0  0.6   0:00.04 postgres
 9534 gitlab-+  20   0  592824  12060   9668 S   0.0  0.6   0:00.01 postgres
 8781 gitlab-+  20   0  592816  11932   9616 S   0.0  0.6   0:00.02 postgres
32684 root      20   0   61856  11420      0 S   0.0  0.6  23:35.39 supervisord
 8100 gitlab-+  20   0   37552  11112   2868 S   0.3  0.5   0:03.74 redis-server
 8094 gitlab-+  20   0  577068   7944   7324 S   0.0  0.4   0:00.01 postgres
 8087 gitlab-+  20   0   46756   7932   2900 S   0.0  0.4   0:00.01 nginx
 8095 gitlab-+  20   0  577068   7052   6444 S   0.0  0.3   0:00.06 postgres
 8088 gitlab-+  20   0   46412   6752   1992 S   0.0  0.3   0:00.10 nginx
  975 root      20   0   38236   6368   1908 S   0.0  0.3   8:47.56 systemd-journal
 8097 gitlab-+  20   0  578076   5600   4240 S   0.0  0.3   0:00.05 postgres
 8086 root      20   0   42240   5524   4696 S   0.0  0.3   0:00.00 nginx
  974 root      20   0   12204   4720     60 S   0.0  0.2   2:33.12 haveged
    1 root      20   0  185260   4308   2408 S   0.0  0.2   3:23.22 systemd
 7757 root      20   0   25224   4256   2484 S   0.0  0.2   0:00.28 bash
 9857 root      20   0   42468   3708   3076 R   0.0  0.2   0:00.09 top
 8098 gitlab-+  20   0   26956   3296   2608 S   0.0  0.2   0:00.08 postgres
 8089 gitlab-+  20   0   42424   3260   2224 S   0.0  0.2   0:00.01 nginx
 8784 git       20   0   18100   2980   2664 S   0.0  0.1   0:00.38 gitlab-unicorn-
 8096 gitlab-+  20   0  577068   2932   2332 S   0.0  0.1   0:00.03 postgres

我已经点击了 pstree，这些捆绑过程似乎与 ruby​​ 应用程序相关（必须是 gitlab）。

systemd─┬─agetty
        ├─atd
        ├─bundle─┬─3*[bundle───{ruby-timer-thr}]
        │        └─{ruby-timer-thr}
...

有没有人有过类似的经历或知道是什么原因造成的？

答案1

这些将是 unicorn 工作者和 sidekiq。它们似乎使用了正确的内存量。2GB 是运行 gitlab 的最低 RAM 要求；如果您的系统有大量活动，则需要 4GB 或更多。

我在 2GB RAM 上也有一个个人 gitlab 实例，它显示了类似的使用情况：

top - 23:30:42 up 5 days,  7:53,  1 user,  load average: 0.04, 0.03, 0.05
Tasks: 172 total,   2 running, 170 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1.2 us,  0.2 sy,  0.0 ni, 98.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  2048816 total,    72636 free,  1762504 used,   213676 buff/cache
KiB Swap:  1048572 total,   801180 free,   247392 used.    73972 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND     
  664 git       20   0  715620 458296   2964 S   3.0 22.4 139:48.55 bundle      
 1623 git       20   0  543608 327472   3044 S   0.0 16.0   3:46.02 bundle      
 1626 git       20   0  543608 324384   3224 S   0.0 15.8   3:51.97 bundle      
 1620 git       20   0  543608 324244   3088 S   0.0 15.8   3:51.68 bundle      
 1556 git       20   0  510840 149736   2616 S   0.0  7.3   0:18.45 bundle

请注意，这top不会向您显示进程实际在做什么，但您可以使用轻松找出答案ps。例如：

# ps 664
  PID TTY      STAT   TIME COMMAND
  664 ?        Ssl  139:49 sidekiq 4.2.1 gitlab-rails [0 of 25 busy]
# ps 1556
  PID TTY      STAT   TIME COMMAND
 1556 ?        Sl     0:18 unicorn master -D -E production -c /var/opt/gitlab/gitlab-rails/etc/unicorn.rb /opt/gitlab/embedded/service/gitlab-rails/config.ru

答案2

GitLab CE 至少需要使用 4GB 的 RAM。因此，如果您有 2GB RAM，GitLab 会尝试使用 SWAP 添加另外 2GB 内存，从而产生 2GB 的交换内存。这会使 GitLab 非常慢，即使您是唯一的用户。

解决方案：您的机器必须至少有 4 GB 或更多的 RAM。不要浪费时间调整 GitLab 的配置文件，只需确保您有 4 GB 的 RAM 即可。

阅读此 GitLab 文档的“内存”部分： https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/install/requirements.md

祝你好运！

答案3

我知道这个帖子有点过时了，但还有其他人遇到过这种情况吗？我使用的是一台 24GB 和 12 核/24 线程的物理机，我看到 bundle 疯狂地分叉，直到它耗尽所有内存。我查看了 gitlab 配置，发现 sidekiq 并发默认设置为 25 - 显然这意味着最多有 25 个 bundle 副本在运行？它会在内存耗尽之前创建尽可能多的副本。疯了。

答案4

在文件中添加以下内容gitlab.rb，重启即可生效：

puma['worker_processes'] = 0
sidekiq['max_concurrency'] = 10
postgresql['shared_buffers'] = "256MB"
prometheus_monitoring['enable'] = false
 
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',
  'GITALY_COMMAND_SPAWN_MAX_PARALLEL' => '2'
}
 
gitaly['concurrency'] = [
  {
    'rpc' => "/gitaly.SmartHTTPService/PostReceivePack",
    'max_per_repo' => 10
  }, {
    'rpc' => "/gitaly.SSHService/SSHUploadPack",
    'max_per_repo' => 4
  }
]

万一这是从哪里来的呢？那就看看这里。

相关内容