Gitlab: чрезвычайно высокое потребление памяти процессом «связки» в ruby


9

У меня проблема с моей установкой Gitlab, работающей на небольшой Ubuntu LTS 16.04. Я должен отметить, что у меня нет большого опыта работы с Linux или Gitlab.

Моя установка на Gitlab с несколькими личными проектами (всего 4) работала нормально, хотя загрузка протекала очень медленно и иногда не удалась. Также доступ к веб-интерфейсу крайне медленный. Я проверил сервер и заметил, что используется до 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}
... 

У кого-нибудь был подобный опыт или идея, которая могла бы вызвать это?

Ответы:


3

GitLab CE хочет использовать как минимум 4 ГБ оперативной памяти. Поэтому, если у вас 2 ГБ ОЗУ, GitLab пытается добавить еще 2 ГБ памяти с помощью SWAP, что приводит к 2 ГБ подменной памяти. Это делает GitLab очень медленным, даже если вы единственный пользователь.

Решение: ваша машина должна иметь как минимум 4 ГБ ОЗУ или более. Не тратьте свое время на настройку файла конфигурации GitLab, просто убедитесь, что у вас 4 ГБ оперативной памяти.

Прочитайте раздел «Память» этого документа GitLab: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/install/requirements.md.

Удачи!


2

Это будут рабочие единорога и сидекик. Похоже, они используют правильный объем памяти. 2 ГБ - это почти минимум оперативной памяти для запуска gitlab; если в вашей системе много активности, вам нужно 4 ГБ или больше.

У меня есть личный экземпляр gitlab на 2 ГБ оперативной памяти, и он показывает аналогичное использование:

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

1
Спасибо за ваш ответ. Я думаю, что мне придется искать более легкое решение. Gogs выглядит многообещающе
mode777

У меня также есть 2 ГБ оперативной памяти, и Gitlab отлично работает в начале. Кажется, что есть утечка памяти на корешке ( gitlab.com/gitlab-org/gitlab-ce/issues/30564 ). Есть некоторые вещи, которые вы можете сделать, например: docs.gitlab.com/ce/administration/operations/… (но я сам этого не сделал) или время от времени перезапускать этот процесс взаимодействия (возможно, cron?).
Josejulio

Убийца единорога также может быть полезен about.gitlab.com/2015/06/05/…
Хосеюлио

Я оцениваю gitlab для проекта и столкнулся с подобной проблемой здесь, в марте 2018 года. Новая блестящая установка Debian на 2-гигабайтном узле, Gitlab работает нормально, но в течение нескольких дней bundleпроцессы потребляют память и вызывают чрезмерную подкачку. Это было исправлено, по крайней мере временно, с gitlab-ctl restart. «У Gitlab есть утечки памяти», - говорится в документации. Да, у него есть утечки с момента его установки, когда он работает вхолостую.
Роджер Халлибертон

Вы можете нажать cсверху, чтобы показать фактические командные строки.
Томас

1

Я знаю, что эта ветка очень старая, но кто-нибудь еще сталкивается с этим? Я на физическом боксе с 24 ГБ и 12 ядрами / 24 нитями, и я вижу, как пакет разветвляется, как сумасшедший, пока он не высосет всю память. Я посмотрел в конфиге gitlab и обнаружил, что параллелизм sidekiq установлен на 25 по умолчанию - очевидно, что означает, что работает до 25 копий пакета? Он создает столько, сколько может, прежде чем из памяти. Сумасшедший.


Обновление Я нашел эту
ветку,

0

Вы пытались выключить, а затем снова включить?

gitlab-ctl restart

Что бы ни происходило bundle, кажется довольно ясным, что инструменты * -killer не решают эти проблемы. Похоже, что эти процессы запускаются из sidekiq.


Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.