htop showing duplicate sidekiq instances

So I just started investigating and attempting to tame the gitlab memory situation. I have 2 instances of gitlab running via docker-compose on an 8G dedicated server. Settings: Both Instances:

unicorn['worker_processes'] = 1  #(was 3)
unicorn['worker_timeout'] = 30  #(was 60)

Instance#1 (default was 25):

sidekiq['concurrency'] = 4 

Instance#2 (default was 25):

sidekiq['concurrency'] = 2 

After running

gitlab-ctl reconfigure 
and
gitlab-ctl restart sidekiq

In htop, I originally had: 8 sidekiqs saying [0 of 4] and 6 sidekiqs saying [0 of 2] then after a night of very few hits on the server: 10 sidekiqs saying [0 of 4] and 8 sidekiqs saying [0 of 2]

so it seems the settings are being used as it says 0 of 4 instead of 0 of 25, however, there are more than 4 of them in htop.

However, however when i run sudo ps aux --sort -rss there is only one sidekiq for each gitlab instance.

However, however, however, ps aux seems to make more sense mathematically, because if i had 18 processes taking 350MB each, that would need 6300MB of memory. Yet htop, and free -m both agree that the server is only using 2925MB of memory.

Can anyone explain these numbers? specifically: Why would there be so many instances shown in htop? Why would they be shown with separate PID each taking 350MB but actually not affect the total memory usage?

/label ~Performance memory usage

changed title from Htop showing duplicate sidekiq instances to htop showing duplicate sidekiq instances

@yorickpeterse I can't add labels, but I hope to get your attention on this issue and ask if you could add the appropriate labels for me.

@gotjosh:

Are you sure the htop output you're using was not displaying the threads for every process? This might give the illusion of multiple child processes. You can change this by starting htop, pressing F2, going to "Display options", then checking "Hide userland process threads".

Thanks @yorickpeterse that explains and solves the issue!

closed