Gitlab: Consumo de memória extremamente alto por processo de "pacote" de ruby

9

Estou com um problema com a instalação do Gitlab em execução em um pequeno Ubuntu LTS 16.04. Devo salientar que não tenho muita experiência com Linux ou Gitlab.

Minha instalação do Gitlab com alguns projetos pessoais (apenas 4) estava funcionando Ok, embora o envio seja extremamente lento e às vezes falhe. O acesso à interface da web também é extremamente lento. Eu verifiquei o servidor e notei que até 96% da memória total foram usados. O culpado parece ser um processo de pacote.

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

Eu bati pstree e esses processos de pacote parecem estar relacionados ao aplicativo ruby ​​(deve ser o gitlab).

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

Alguém já teve experiências semelhantes ou uma idéia do que pode causar isso?

linux ruby gitlab ubuntu-16.04 mode777
fonte

Respostas:

3

O GitLab CE deseja usar pelo menos 4 GB de RAM. Portanto, se você tem 2 GB de RAM, o GitLab tenta adicionar outros 2 GB de memória usando SWAP, o que resulta em 2 GB de memória de troca. Isso torna o GitLab muito lento, mesmo se você for o único usuário.

A solução: sua máquina deve ter pelo menos 4 GB de RAM ou mais. Não perca tempo ajustando o arquivo de configuração do GitLab, apenas certifique-se de ter 4 GB de RAM.

Leia a seção 'Memória' deste documento do GitLab: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/install/requirements.md

Boa sorte!

AndaluZ
fonte
2

Esses serão os trabalhadores do unicórnio e o sidekiq. Eles parecem estar usando a quantidade correta de memória. 2 GB é o mínimo de RAM para rodar o gitlab; se o seu sistema tiver muita atividade, você precisará de 4 GB ou mais.

Também tenho uma instância pessoal do gitlab com 2 GB de RAM e mostra um uso semelhante:

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

Observe que topnão mostra o que os processos estão realmente fazendo, mas você pode descobrir com facilidade ps. Por exemplo:

# 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
Michael Hampton
fonte
1
Obrigado pela sua resposta. Acho que vou ter que procurar uma solução mais leve. Gogs parece promissor
mode777
Eu também tenho 2GB de RAM e o gitlab funciona bem no começo. Parece que há um vazamento de memória no ajudante ( gitlab.com/gitlab-org/gitlab-ce/issues/30564 ). Há algumas coisas que você pode fazer como: docs.gitlab.com/ce/administration/operations/… (mas ainda não fiz isso) ou reinicie esse processo de vez em quando (talvez um cron?).
Josejulio 6/07/07
O assassino de unicórnio também pode ser útil about.gitlab.com/2015/06/05/…
Josejulio 6/17/17
Estou avaliando o gitlab para um projeto e encontrei um problema semelhante, aqui em março de 2018. Uma nova instalação Debian brilhante em um nó de 2 GB, o Gitlab funciona bem, mas em alguns dias os bundleprocessos consomem memória e causam troca excessiva. Isso foi corrigido, pelo menos temporariamente, com gitlab-ctl restart. "O Gitlab tem vazamentos de memória", diz a documentação. Sim, há vazamentos a partir do momento em que você o instala, quando está ocioso.
Roger Halliburton
Você pode pressionar cna parte superior para mostrar as linhas de comando reais.
Thomas
1

Eu sei que este tópico é muito antigo, mas alguém ainda o encontra? Estou em uma caixa física com 24GB e 12cores / 24threads e estou vendo o pacote bifurcado como um louco até que consuma toda a memória. Eu olhei na configuração do gitlab e constatei que a simultaneidade do sidekiq está definida como 25 por padrão - aparentemente isso significa até 25 cópias do pacote em execução? Ele cria o maior número possível antes da memória. Louco.

BoeroBoy
fonte
Atualização Encontrei este tópico que ajuda: stackoverflow.com/questions/36122421/…
BoeroBoy
0

Você já tentou desligá-lo e ligá-lo novamente?

gitlab-ctl restart

Seja o que for que esteja acontecendo bundle, parece bem claro que as ferramentas * -killer não estão capturando esses problemas. Parece que esses processos foram iniciados no sidekiq.

Roger Halliburton
fonte