Смотря на htop
на моем сервере я вижу 25 процессов sidekiq, порожденных Gitlab. Я использую Gitlab в частном порядке, поэтому никогда не будет никакой нагрузки, поэтому я сомневаюсь, что все эти процессы необходимы, но я не вижу, как настроить их количество.
Есть ли смысл мне беспокоиться об этом на сервере с ограниченными ресурсами?
Я редактировал аргументы запуска Sidekiq. В GitLab <7.0.0 он находится под scripts/background_jobs
но в> 7.0.0 он ниже bin/background_jobs
Изменить:
function start_sidekiq
{
bundle exec sidekiq -q post_receive -q mailer -q system_hook -q project_web_hook -q gitlab_shell -q common -q default -e $RAILS_ENV -P $sidekiq_pidfile $@ >> $sidekiq_logfile 2>&1
}
Кому:
function start_sidekiq
{
bundle exec sidekiq -c 10 -q post_receive -q mailer -q system_hook -q project_web_hook -q gitlab_shell -q common -q default -e $RAILS_ENV -P $sidekiq_pidfile $@ >> $sidekiq_logfile 2>&1
}
Обратите внимание на -c 10
. Измените это на то, что хотите.
Конечно, проверьте эту ветку здесь: https://github.com/gitlabhq/gitlabhq/issues/2780
Просто отредактируйте файл sidekiq config.yml, обратите внимание на параметр параллелизма: https://github.com/mperham/sidekiq/blob/master/examples/config.yml
В установке Debian версии 9.3.0 у меня было /etc/gitlab/gitlab.rb
в которых есть строки конфигурации для sidekiq.
+ Изменить
# sidekiq['concurrency'] = 25
на любой номер, который вам кажется подходящим:
sidekiq['concurrency'] = 5
(Причина, по которой я изменил себя, заключалась в том, что 25 процессов по умолчанию потребляли много оперативной памяти, что приводило к использованию подкачки, что, в свою очередь, делало gitlab очень медленным. После этого изменения производительность значительно улучшилась для меня)
Большинство предлагаемых решений этой проблемы как в этой ветке вопросов и ответов, так и в других местах сети кажутся устаревшими, но проблема все еще актуально, поэтому вот мое решение для Gitlab 9.5.3 на Archlinux с использованием пакетов сообщества:
Мне не удалось заставить это работать, добавив sidekick.yml
, sidekick_queues.yml
, или что-либо еще в / etc и прибегли к непосредственному взлому установленного источника пакета.
Отредактируйте системный файл /usr/share/webapps/gitlab/config/sidekiq_queues.yml
и добавьте эту строку сразу после открытия ---
Маркер YAML:
:concurrency: 5
В результате YAML выглядит примерно так:
затем sudo systemctl restart gitlab-sidekiq
и в итоге я получил только 5 потоков, пережевывающих память вместо 25.
Для меня сработало просто пойти в /home/git/gitlab/config
. Был sidekiq.yml.example
файл. Я только что побежал:
$ cd /home/git/gitlab/config
$ cp sidekiq.yml.example sidekiq.yml
С помощью vim sidekiq.yml
вы увидите, что есть :concurrency:
вариант. Задайте необходимое количество процессов sidekiq, сохраните файл и запустите service gitlab restart
.
Отказ от ответственности: расположение папки установки GitLab может отличаться. Для меня это было /home/git/gitlab
У меня установлена версия gitlab "из источника", и мне пришлось отредактировать config/sidekiq_queues.yml
и добавить :concurrency: X
(где X - желаемое количество процессов.
В sidekiq.yml
не используется gitlab. Вы можете увидеть это, если посмотрите на запущенный процесс и его параметр -C.