25 processos Sidekiq para o Gitlab

Question

Olhando para htop output no meu servidor, vejo 25 processos sidekiq gerados pelo Gitlab. Eu uso o Gitlab em particular, então nunca haverá carga, então duvido que todos esses processos sejam necessários, mas não consigo ver como configurar o número deles.

Existe algum ponto para eu me preocupar com isso em um servidor com recursos restritos?

    

Answer 1

Claro, verifique este tópico aqui: link

Apenas edite o arquivo sidekiq config.yml, observe a opção de simultaneidade: link

    

Answer 2

Eu editei os argumentos de inicialização do Sidekiq. No GitLab < 7.0.0 está sob scripts/background_jobs mas em > 7.0.0 está sob bin/background_jobs

Alteração:

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
}

Para:

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
}

Observe o -c 10 . Mude isso para o que você quiser.

    

Answer 3

Na instalação Debian da versão 9.3.0 eu tinha /etc/gitlab/gitlab.rb que tem linhas de configuração para o sidekiq.

Alterar

# sidekiq['concurrency'] = 25

para o número que você achar adequado:

sidekiq['concurrency'] = 5

(O motivo pelo qual eu mudei foi porque os 25 processos padrão consumiam muito memória RAM, fazendo com que a troca fosse usada, o que tornava o gitlab muito lento. O desempenho melhorou muito para mim depois dessa mudança)

    

Answer 4

A maioria das soluções propostas para este problema, tanto neste thread de Q & A como noutros locais, parece estar desatualizada, mas o problema ainda é actual, por isso aqui está a minha solução para o Gitlab 9.5.3 no Archlinux usando os pacotes da comunidade:

Não consegui fazer isso funcionar adicionando sidekick.yml , sidekick_queues.yml ou qualquer outra coisa em / etc e recorri a hackear diretamente a fonte do pacote instalado.

Edite o arquivo do sistema /usr/share/webapps/gitlab/config/sidekiq_queues.yml e adicione essa linha logo após o marcador --- YAML de abertura:

:concurrency: 5

O YAML resultante é algo assim:

Então, sudo systemctl restart gitlab-sidekiq e finalmente consegui apenas 5 threads mastigando memória em vez de 25.

    

Answer 5

Para mim, funcionou apenas ir para /home/git/gitlab/config . Havia um arquivo sidekiq.yml.example . Eu apenas corri:

$ cd /home/git/gitlab/config
$ cp sidekiq.yml.example sidekiq.yml

Usando vim sidekiq.yml , você verá que há uma opção :concurrency: . Configure-o para o número de processos sidekiq que você deseja, salve o arquivo e execute service gitlab restart .

Aviso: o local da sua pasta de instalação do GitLab pode variar. Para mim foi /home/git/gitlab

    

Answer 6

Eu tenho uma versão do gitlab "de origem" instalada e tive que editar config/sidekiq_queues.yml e adicionar :concurrency: X (onde X é o número desejado de processos.

O sidekiq.yml não é usado pelo gitlab. Você pode ver isso se olhar o processo em execução e sua opção -C.