У меня проблема с моей установкой 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}
...
У кого-нибудь был подобный опыт или идея, что может вызвать это?
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 ГБ - это минимум оперативной памяти для запуска 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
Я знаю, что эта ветка немного устарела, но кто-нибудь еще сталкивался с этим? Я нахожусь на физическом ящике с 24 ГБ и 12 ядрами / 24 потоками, и я вижу, что пакет разветвляется как сумасшедший, пока он не заберет всю память. Я просмотрел конфигурацию gitlab и обнаружил, что параллелизм sidekiq по умолчанию установлен на 25 - по-видимому, это означает, что работает до 25 копий пакета? Он создает столько, сколько может раньше, из памяти. Псих.
Вы пробовали выключить его, а затем снова включить?
gitlab-ctl restart
Что бы ни случилось с bundle, кажется довольно очевидным, что инструменты * -killer не улавливают эти проблемы. Похоже, эти процессы запускаются с sidekiq.
На gitlab.com есть проблема по этому поводу # 40816.
Кажется, что установка более высокого значения 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'
}