Pretty frequently seeing high CPU usage and it’s usually around the 85% mark: [Screenshot 2025-01-25 at 00.47.46] Was previously showing up as unicorn.conf.r: [Screenshot 2025-01-25 at 01.43.52] Could this indicate UNICORN_WORKERS being set too high/low? The server has 64GB RAM (usually shows…

[画像] 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 the server loads have gone back to what they were (less than half of what they had gone…

Yep. I also suggest decreasing the number of unicorn workers: [画像] How to avoid upstream timeouts? 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…

You could try reducing unicorn workers.

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 has…

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.

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 , where he quotes Jeff saying 1 worker per core? From my own experiments, 1 worker per core results in…

Take a look at discourse-setup, which handles the scaling for new installs today: # 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=$(( u…

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 …

FWIW, there are no long-running or failed jobs in sidekiq.

I rebuilt with no plugins (except docker manager) and the problem persists, so it’s not a plugin’s fault. Any clues here? [image] [image] [image]

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…

CPU使用率が高い（Ruby）

サポート

AstonJ (AstonJ) 2025 年 2 月 3 日午前 11:28 18

どうやら私の問題はユニコーンワーカーではなかったようです。@sam が @LotusJeff のスレッドに続くアップデートを行った後、サーバーの負荷は以前の状態（最大値の半分未満）に戻りました…

「いいね！」 4

トピック		返信	表示
Recommendation for number of workers: cores × 2? Self-hosting	16	313	2025 年 4 月 29 日
Due to extreme load, this is temporarily being shown to everyone... when it's not really the case Self-hosting server-resources	19	1709	2023 年 7 月 21 日
Optimizing the number of Unicorns and buffer size Self-hosting server-resources	24	6827	2020 年 12 月 13 日
Browser upgrade fails when discourse is configured to use one unicorn worker Bug	5	421	2023 年 10 月 18 日
How to avoid upstream timeouts? Support	26	9382	2022 年 3 月 26 日

CPU使用率が高い（Ruby）

関連トピック