100% cpu usage

Hi,

after upgrade 8.14 to 8.16.4 Gitlab, some processes bundle or ruby take all then CPU.
I saw that it’s the unicorn process which do that, I change the unicorn parameters in gitlab.rb file

unicorn['worker_processes'] = 4
unicorn['worker_timeout'] = 30

But never change

There’s no background processes.

Can you help me ?

Same here. Now I am trying to get back to 8.16.3 and see if it fixes. any ideas?

Anyone figure out how to resolve this problem? Bundle processes pegging a CPU all the time.

I’m on GitLab Enterprise Edition 8.17.2-ee GitLab Enterprise Edition 8.17.2-ee with only 2 projects and two users.

Only solution so far is to stop gitlab unless we are using it.

Looks like this is a common issue. Solutions range from increasing the unicron workers to regularly restarting the gitlab service via a cronjob.

See the GitLab EE forums and this blog for more info.

Two users (rarely used), 4 cores, 8 GB RAM on ubuntu…and I can’t let gitlab run because it hangs the server after 15 minutes or so. If I stop sidekiq then it can run for 12 hours or so before hanging.

I’m on the most current version of EE. I’ve lowered the number of sidekiq’s and workers to 2 or 3 to no avail.

Any suggestions? As it is now, it’s a pretty useless piece of software for me unfortunately.

This issue is still happening for me, more or less after doing random git things (fetch, pull, push) and on both of my GitLab servers, one on Debian, one on Ubuntu.

It can happen right after a power off - power on event as well.

It takes all the processor power - all of it. I am very disappointed. This kind of software is a big risk. Completely impossible to install in the production. This kind of issues should not even exists if the product is published as status “ready”.

In my case, while shutting down the service, it pops up again…

:frowning: :frowning:

What is the spec of your server @miguelahonen ?? How many CPU, RAM, disk did you allocate to your server? Mine is running in production for 3 - 4 years and no problems, so it’s obviously something unique to your configuration.