Gitlab：Rubyの「バンドル」プロセスによる非常に高いメモリ消費

小さなUbuntu LTS 16.04で実行しているGitlabインストールに問題があります。LinuxやGitlabの経験があまりないことを指摘しなければなりません。

いくつかの個人プロジェクト（4つのみ）を含むGitlabインストールは正常に実行されていましたが、プッシュは非常に遅く、失敗することがあります。また、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}
... 

誰かが同様の経験やこれを引き起こす可能性があるアイデアを持っていますか？

GitLab CEは、少なくとも4GBのRAMを使用したいと考えています。したがって、2GBのRAMがある場合、GitLabはSWAPを使用してさらに2GBのメモリを追加しようとします。その結果、2GBのスワップメモリ​​が発生します。これにより、たとえあなたが唯一のユーザーであっても、GitLabは非常に遅くなります。

解決策：マシンには少なくとも4 GB以上のRAMが必要です。GitLabの構成ファイルの調整に時間を無駄にしないでください。4GBのRAMが搭載されていることを確認してください。

このGitLabのドキュメントの「メモリ」セクションをお読みください：https ://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/install/requirements.md

幸運を！

それらはユニコーンワーカーと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

私はこのスレッドが少し古いことを知っていますが、他の誰かがまだこれに遭遇していますか？私は24GBと12cores / 24threadsの物理的なボックスを使用していて、すべてのメモリを使い果たすまで、バンドルがmadのように分岐しているのを見ています。私はgitlab configを調べたところ、sidekiqの同時実行性がデフォルトで25に設定されていることがわかりました-明らかにそれは、実行されているバンドルの最大25のコピーを意味しますか？それは、メモリ不足になる前にできるだけ多くを作成します。クレイジー。

オフにしてから再度オンにしてみましたか？

gitlab-ctl restart

で何が起こっていてbundleも、*-killerツールがこれらの問題を捕捉していないことは明らかです。これらのプロセスはsidekiqから開始されているようです。

この＃40816についてはgitlab.comに問題があります。

MIN + MAXを高く設定することが役立つようです：https : //docs.gitlab.com/ee/user/gitlab_com/index.html#unicorn

私が使う：

        gitlab_rails['env'] = {
          'GITLAB_UNICORN_MEMORY_MIN' => '786432000',
          'GITLAB_UNICORN_MEMORY_MAX' => '1572864000'
        }