Gitlab : 루비 "번들"프로세스에 의한 매우 높은 메모리 소비

작은 Ubuntu LTS 16.04에서 실행중인 Gitlab 설치에 문제가 있습니다. 나는 리눅스 나 Gitlab에 대한 경험이 많지 않다는 것을 지적해야한다.

푸시가 매우 느리고 때로는 실패하지만 몇 가지 개인 프로젝트 (4 개만)가있는 Gitlab 설치가 Ok를 실행 중이었습니다. 또한 웹 인터페이스에 액세스하는 것이 매우 느립니다. 서버를 확인한 결과 총 메모리의 최대 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를 쳤고이 번들 프로세스는 루비 응용 프로그램과 관련이있는 것 같습니다 (gitlab이어야 함).

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

누구나 비슷한 경험이나이를 일으킬 수있는 아이디어가 있습니까?

GitLab CE는 최소 4GB의 RAM을 사용하려고합니다. 따라서 2GB RAM이있는 경우 GitLab은 SWAP를 사용하여 2GB의 메모리를 추가하려고 시도하므로 2GB의 스왑 메모리가 생성됩니다. 이것은 당신이 유일한 사용자 일지라도 GitLab을 매우 느리게 만듭니다.

해결 방법 : 컴퓨터에 4GB 이상의 RAM이 있어야합니다. GitLab의 구성 파일을 수정하는 데 시간을 낭비하지 말고 하드 4GB의 RAM이 있는지 확인하십시오.

이 GitLab 문서의 '메모리'섹션을 읽으십시오 : https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/install/requirements.md

행운을 빕니다!

그것들은 유니콘 노동자와 사이드 키크가 될 것입니다. 올바른 양의 메모리를 사용하고있는 것 같습니다. 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의 물리적 상자에 있으며 모든 메모리를 빨아 들일 때까지 번들처럼 미친 듯이 보입니다. gitlab 구성을 살펴본 결과 sidekiq 동시성이 기본적으로 25로 설정되어 있음을 알았습니다. 분명히 최대 25 개의 번들 사본이 실행되고 있습니까? 메모리가 부족하기 전에 최대한 많이 만듭니다. 미친.

전원을 껐다가 다시 켜 보셨습니까?

gitlab-ctl restart

로 무슨 일이 일어나고 bundle있더라도 * 킬러 도구가 이러한 문제를 포착하지 못한다는 것이 분명합니다. 이러한 프로세스는 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'
        }