# High CPU usage (Ruby)
**URL:** https://meta.discourse.org/t/high-cpu-usage-ruby/348913
**Category:** Support
**Tags:** server-resources
**Created:** [January 25, 2025, 1:50am UTC](https://meta.discourse.org/t/high-cpu-usage-ruby/348913 "2025-01-25T01:50:40Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@AstonJ](https://meta.discourse.org/u/AstonJ)
#### Post date: [January 25, 2025, 1:50am UTC](https://meta.discourse.org/t/high-cpu-usage-ruby/348913/1 "2025-01-25T01:50:40Z")
Pretty frequently seeing high CPU usage and it’s usually around the 85% mark:
Was previously showing up as `unicorn.conf.r`:
Could this indicate `UNICORN_WORKERS` being set too high/low?
The server has 64GB RAM (usually shows around 40GB free) and 6 cores, there are 4 Discourse instances on the server each set to `UNICORN_WORKERS: 8`
Any ideas or tips on what’s causing it or what to try? (One of the forums is in read-only mode and doesn’t get much traffic, should it be set to have fewer workers?)
---
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [January 25, 2025, 9:16am UTC](https://meta.discourse.org/t/high-cpu-usage-ruby/348913/2 "2025-01-25T09:16:09Z")
I don’t know but my bet is you are using way more workers than what your cores can offer?
---
### Author:  [@NateDhaliwal](https://meta.discourse.org/u/NateDhaliwal)
#### Post date: [January 25, 2025, 9:22am UTC](https://meta.discourse.org/t/high-cpu-usage-ruby/348913/3 "2025-01-25T09:22:44Z")
Yep. I also suggest decreasing the number of unicorn workers:
> [@How to avoid upstream timeouts?](https://meta.discourse.org/t/how-to-avoid-upstream-timeouts/35483/4):
>
> General advice is **one worker per CPU core (real or logical)**. I would allow at least 512mb ram per worker as well, so here is hoping you have at least 512mb times the number of logical cores on your server
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [January 25, 2025, 10:25am UTC](https://meta.discourse.org/t/high-cpu-usage-ruby/348913/4 "2025-01-25T10:25:07Z")
You could try reducing unicorn workers.
---
### Author:  [@AstonJ](https://meta.discourse.org/u/AstonJ)
#### Post date: [January 26, 2025, 12:25am UTC](https://meta.discourse.org/t/high-cpu-usage-ruby/348913/5 "2025-01-26T00:25:05Z")
Thanks for the replies everyone - not sure where I read it now but I always thought we were to set 2 workers per core. I’ve dropped the workers down now per forum, allocating more to the busiest forums and less to the ones not as busy. I’ll monitor things over the next week and report back if it hasn’t help.
**Edit** : Think I read it [here](https://meta.discourse.org/t/users-kicked-out-of-topic-more-memory-required/163855/10).
---
### Author:  [@Stephen](https://meta.discourse.org/u/Stephen)
#### Post date: [January 28, 2025, 5:52pm UTC](https://meta.discourse.org/t/high-cpu-usage-ruby/348913/6 "2025-01-28T17:52:06Z")
In your case you aren’t allocating two workers per core though. You have six cores which would mean twelve workers, but you have four instances each using eight workers, so 32 total.
---
### Author:  [@AstonJ](https://meta.discourse.org/u/AstonJ)
#### Post date: [January 28, 2025, 5:58pm UTC](https://meta.discourse.org/t/high-cpu-usage-ruby/348913/7 "2025-01-28T17:58:38Z")
Yep… I’ve adjusted so the total number of workers is not greater than twice the number of cores, though I still wonder - what’s the correct/standard advice, what you said or what was in [Nate’s post](https://meta.discourse.org/t/high-cpu-usage-ruby/348913/3), where he quotes Jeff saying 1 worker per core?
From my own experiments, 1 worker per core results in timeouts (but lowers server load) more workers results in better performance but higher load (which on my server is still within an acceptable range).
---
### Author:  [@Stephen](https://meta.discourse.org/u/Stephen)
#### Post date: [January 28, 2025, 9:57pm UTC](https://meta.discourse.org/t/high-cpu-usage-ruby/348913/9 "2025-01-28T21:57:31Z")
Take a look at discourse-setup, which handles the scaling for new installs today:
```plaintext
# UNICORN_WORKERS: 2 * GB for 2GB or less, or 2 * CPU, max 8
if ["$avail_gb" -le "2"]
then
unicorn_workers=$(( 2 * $avail_gb ))
else
unicorn_workers=$(( 2 * $avail_cores ))
fi
unicorn_workers=$(( unicorn_workers < 8 ? unicorn_workers : 8 ))
```
That second statement, using double the number of available cores, is the default on systems with more than 2GB RAM. It looks as though your issue is more down to a tug-of-war between your instances (host resources), rather than a discourse problem.
---
### Author:  [@markschmucker](https://meta.discourse.org/u/markschmucker)
#### Post date: [January 29, 2025, 4:31pm UTC](https://meta.discourse.org/t/high-cpu-usage-ruby/348913/10 "2025-01-29T16:31:02Z")
I’m seeing the same thing after my last upgrade, which was one day after the OP, so I don’t think this has anything to do with the number of unicorn workers. **The `unicorn.conf.r*` process is suspicious, because the original post of this topic is the only hit for that term on the entire web.** I believe unicorn.conf.rb would be more normal.
The increase happened at exactly my last upgrade, 4 days ago. Note the OP posted 5 days ago. Something changed in Discourse.
I’ve used the same number of unicorn workers on the same instance for several years, and didn’t change anything- just rebuilt to 3.4.0.beta4-dev.
---
### Author:  [@markschmucker](https://meta.discourse.org/u/markschmucker)
#### Post date: [January 29, 2025, 9:09pm UTC](https://meta.discourse.org/t/high-cpu-usage-ruby/348913/11 "2025-01-29T21:09:01Z")
FWIW, there are no long-running or failed jobs in sidekiq.
---
### Author:  [@markschmucker](https://meta.discourse.org/u/markschmucker)
#### Post date: [January 30, 2025, 1:30pm UTC](https://meta.discourse.org/t/high-cpu-usage-ruby/348913/12 "2025-01-30T13:30:14Z")
I rebuilt with no plugins (except docker manager) and the problem persists, so it’s not a plugin’s fault.
Any clues here?
---
### Author:  [@AstonJ](https://meta.discourse.org/u/AstonJ)
#### Post date: [January 30, 2025, 5:34pm UTC](https://meta.discourse.org/t/high-cpu-usage-ruby/348913/13 "2025-01-30T17:34:49Z")
I’ve just upgraded to the latest Discourse and haven’t seen anymore `unicorn.conf.r*` (now anything around the 80% cpu mark is just `ruby`, though seems less frequent). Loads are around the same (though lower than they were after I made those worker adjustments).
Have you upgraded to the latest version? What kind of hardware are you on and how busy in your forum?
---
### Author:  [@markschmucker](https://meta.discourse.org/u/markschmucker)
#### Post date: [January 30, 2025, 5:47pm UTC](https://meta.discourse.org/t/high-cpu-usage-ruby/348913/14 "2025-01-30T17:47:59Z")
> [@AstonJ](#):
>
> Have you upgraded to the latest version?
Yes, I’m at 3.4.0.beta4-dev. That’s what started the high CPU usage. Nothing else changed.
> [@AstonJ](#):
>
> What kind of hardware are you on and how busy in your forum?
8 GB RAM, 2 vCPUs, 160 GB SSD with plenty of space.
I posted the CPU usage above for my production site, which has around 30 users online at a time. But **I have a test site with the same issue and there is absolutely no traffic and no plugins there**. CPU usage before and after updating (spikes are daily backups):
---
### Author:  [@AstonJ](https://meta.discourse.org/u/AstonJ)
#### Post date: [January 31, 2025, 9:24am UTC](https://meta.discourse.org/t/high-cpu-usage-ruby/348913/15 "2025-01-31T09:24:50Z")
I’m not sure whether our situations are related Mark. I think in my case what Stephen said played a large part:
> [@Stephen](#):
>
> It looks as though your issue is more down to a tug-of-war between your instances (host resources), rather than a discourse problem.
I recently moved two other instances on to the same server and had actually forgotten that the unicorn workers were set to 8 because previously we were on a server with more cores (but it had it’s own problems hence we moved back to a Xeon which had fewer cores but performed better overall).
So what I found was reducing the unicorn workers on this server reduced load, but started giving us timeouts, increasing them eradicated timeouts but resulted in a higher load - though still within an acceptable range. I think I could increase workers and we could still handle the increased load, but what we have now is good for now.
Having said that, I had moved the instances on to the same server and it was running within what I would have expected (so load increased but not by a huge amount) and it did feel that an update resulted in higher loads… however I cannot be sure of that, and we have to keep in mind that from time to time with Discourse getting more features it may require more powerful hardware or result in sometimes feeling ‘slower’ (I had some Discourse instances on old versions and they felt noticeably snappier - though of course they didn’t have all the features of the newer versions).
Having said that as well, I think loads have actually decreased a little since the latest Discourse update (with PG 15).
I’m not sure what to suggest for you Mark - maybe play around with workers and some of the other settings too? Such as `db_shared_buffers` and `db_work_mem`? Perhaps start a dedicated thread along the lines of “High CPU usage after update - does my instance need perf tweaks?” Or something like that 🙂
---
### Author:  [@LotusJeff](https://meta.discourse.org/u/LotusJeff)
#### Post date: [February 1, 2025, 4:17am UTC](https://meta.discourse.org/t/high-cpu-usage-ruby/348913/16 "2025-02-01T04:17:27Z")
I upgraded tonight and immediately saw a difference in CPU usage on my site. Here is a graph of before, during, and after the upgrade. This represents a one-hour duration.
Standard Discourse single container install running on a DO - 8 GB RAM, 2 vCPUs, and 100 GB SSD with plenty of space.
We will see what it looks like after 12 hours.
---
### Author:  [@LotusJeff](https://meta.discourse.org/u/LotusJeff)
#### Post date: [February 1, 2025, 7:18pm UTC](https://meta.discourse.org/t/high-cpu-usage-ruby/348913/17 "2025-02-01T19:18:32Z")
Here are the results after 15 hours since the upgrade. CPU usage percentage is drastically increased by 3X. Load Factor has increased by 4x.
| Min Avg. | Pre-Upgrade | Post-Upgrade |
| --- | --- | --- |
| 5 | .11 | .4 |
| 15 | .10 | .45 |
24 hour view:
Java is the main CPU use. Something has drastically changed in the latest upgrade.
What info does the Discourse team need to troubleshoot?
Should this topic be moved over to a Bug?
---
### Author:  [@AstonJ](https://meta.discourse.org/u/AstonJ)
#### Post date: [February 3, 2025, 11:28am UTC](https://meta.discourse.org/t/high-cpu-usage-ruby/348913/18 "2025-02-03T11:28:43Z")
> [@AstonJ](#):
>
> So what I found was reducing the unicorn workers on this server reduced load…
So it looks like my issue wasn’t the unicorn workers after all - after @sam’s update following @LotusJeff’s [thread](https://meta.discourse.org/t/increased-cpu-usage-since-3-4-0-beta4-dev-58f75ed205-upgrade/350200/5) the server loads have gone back to what they were (less than half of what they had gone up to)…
> [@Increased CPU Usage since 3.4.0.beta4-dev ( 58f75ed205 ) upgrade](https://meta.discourse.org/t/increased-cpu-usage-since-3-4-0-beta4-dev-58f75ed205-upgrade/350200/5):
>
> OK this is reverted now, [https://github.com/discourse/discourse/pull/31119](https://github.com/discourse/discourse/pull/31119) Let me know if the commit restores performance.
---
### Author:  [@markschmucker](https://meta.discourse.org/u/markschmucker)
#### Post date: [February 3, 2025, 2:02pm UTC](https://meta.discourse.org/t/high-cpu-usage-ruby/348913/19 "2025-02-03T14:02:24Z")
This fixed my problem too.
---
### Author:  [@AstonJ](https://meta.discourse.org/u/AstonJ)
#### Post date: [February 3, 2025, 2:22pm UTC](https://meta.discourse.org/t/high-cpu-usage-ruby/348913/20 "2025-02-03T14:22:38Z")
I probably wouldn’t have noticed if I hadn’t been keeping an eye on the server after having recently moved the other two forums on it - I wonder how many people it affected without them even realising?
Does the Discourse team have measures put in place to alert them of issues like this? Perhaps a volunteer program that admins can set up for specific topics, eg, “Send server loads to Discourse within XX hours/days/weeks before/after an upgrade” Or better still track these locally and then alert admins when server load increases are noticed after upgrades - which we can then post here if need be..
---
### Author:  [@LotusJeff](https://meta.discourse.org/u/LotusJeff)
#### Post date: [February 3, 2025, 3:46pm UTC](https://meta.discourse.org/t/high-cpu-usage-ruby/348913/21 "2025-02-03T15:46:37Z")
I probably would not have noticed the impact, but I am monitoring the server closely because we migrated to Discourse about 2 weeks ago. I am in the weeds doing various post-migration validations (backup run, etc.). After a couple of months, I would never have noticed the impact.
I would hope that discourse has a daily load test running. In my past life, I had a server that would rebuild daily with committed code. It had simulated users using the server all day. We measured key performance metrics from a user perspective and a server perspective. It allowed us to proactively catch memory leaks, inefficient code, and unexpected changes to UX.
I still have to give Kudos to Sam and the team. Coming from the land of phpBB, where something like this would take decades to solve and remedy, I found the fast response terrific. (Even if it meant staying up to 2am CT time compared to Sydney time.)
[Next page](https://meta.discourse.org/t/high-cpu-usage-ruby/348913.md?page=2)