25 Sidekiq processes for Gitlab

Looking at htop output on my server I see 25 sidekiq processes spawned by Gitlab. I use Gitlab privately, so there is never going to be any load, so I doubt all of those processes are required, but I cannot see how to configure their number.

Is there actually any point for me to bother about that on a resource-restricted server?

Solution 1:

Sure, check this thread here: https://github.com/gitlabhq/gitlabhq/issues/2780

Just edit the sidekiq config.yml, note the concurrency option: https://github.com/mperham/sidekiq/blob/master/examples/config.yml

Solution 2:

I edited the Sidekiq startup arguments. In GitLab <7.0.0 it's under scripts/background_jobs but in >7.0.0 it's under bin/background_jobs

Change:

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
}

To:

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
}

Notice the -c 10. Change that to whatever you want.

Solution 3:

In Debian install of version 9.3.0 I had /etc/gitlab/gitlab.rb which have configuration lines for sidekiq.

Change

# sidekiq['concurrency'] = 25

to whatever number you seem fit:

sidekiq['concurrency'] = 5

(Reason I changed my self was because the default 25 processes ate a lot of ram causing swap to be used, in turn making gitlab real slow. Performance improved alot for me after this change)

Solution 4:

Most of the proposed solutions to this problem both in this Q&A thread and elsewhere on line seem to be out of date, but the problem is still current, so here is my solution for Gitlab 9.5.3 on Archlinux using the community packages:

I was unable to get this to work by adding a sidekick.yml, sidekick_queues.yml, or to anything else in /etc and resorted to hacking the installed package source directly.

Edit the system file /usr/share/webapps/gitlab/config/sidekiq_queues.yml and add this line just after the opening --- YAML marker:

:concurrency: 5

The resulting YAML looks something like this:

Then sudo systemctl restart gitlab-sidekiq and I finally got only 5 threads chewing through memory instead of 25.