Eu tenho um problema com a minha instalação do Gitlab rodando em um pequeno Ubuntu LTS 16.04. Eu tenho que salientar que não tenho muita experiência com Linux ou Gitlab.
Minha instalação do Gitlab com alguns projetos pessoais (apenas 4) estava rodando Ok, embora o push seja extremamente lento e às vezes falhe. Também acessar a interface da web é extremamente lento. Eu verifiquei o servidor e notei que até 96% da memória total foram utilizados. 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 acertei o pstree e esses processos do 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 teve experiências semelhantes ou uma ideia do que poderia causar isso?
O GitLab CE quer usar pelo menos 4 GB de RAM. Então, se você tem 2 GB de RAM, o GitLab tenta adicionar mais 2 GB de memória usando o SWAP, o que resulta em 2 GB de memória swap. 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 desperdice seu 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: link
Boa sorte!
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 em 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
Note que top não mostra o que os processos estão realmente fazendo, mas você pode facilmente descobrir com 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
Eu sei que esse segmento é um pouco velho, mas alguém ainda encontra isso? Eu estou em uma caixa física com 24GB e 12cores / 24threads e estou vendo pacote bifurcado como louco até que suga toda a memória. Eu olhei no gitlab config e descobri que a simultaneidade do sidekiq está configurada como 25 por padrão - aparentemente isso significa que até 25 cópias do pacote rodam? Cria tantas quanto pode antes de sair da memória. Louco.
Já tentou desligá-lo e ligá-lo novamente?
gitlab-ctl restart
O que quer que esteja acontecendo com bundle , parece bastante claro que as ferramentas * -killer não estão capturando esses problemas. Parece que esses processos são iniciados no sidekiq.
Tags ruby gitlab linux ubuntu-16.04