Hi everyone, we’re trying to troubleshoot the issues our Discourse installation has been having in the last few days. We’re running a Contabo cloud vps, 8 cores/32gb/nvme, for a userbase of ~150 people; we’ve had few issues in the last 2 and a half years. Since last weekend, the instance is having moments of almost-unusability, due to a un unusually high CPU usage. To troubleshoot this situation, we’ve let the forum in Read Only mode yesterday. I have a few Grafana graphs showing what’s our situation - the three markers indicate where we turned on Read Only, when we restarted the container and when we turned off Read Only. [VwqgTMG] [Qn7qpjb] [aOui8wQ] (a couple more graphs here: Imgur: The magic of the Internet ) As you can see, usage is pretty high. This started a few days ago, therefore there’s some kind of issue we’ve yet to troubleshoot properly. The unusual thing we noticed is that our host reboots the vps during nighttime on sunday, and last weekend the database didn’t manage to complete one or more transactions. We think this might have created inconsistencies in some kind of internal Discourse process, and this inconsistency is fighting against user activity - but we’re simply hypothesizing, here. After asking the AI assistant before opening a new thread, I can add that Sidekiq has some outlier processes: Jobs::ProcessBadgeBacklog takes about 2-5 seconds last DestroyOldDeletionStubs took 475 seconds. last DirectoryRefreshDaily took 580 seconds. last TopRefreshToday took 18 seconds. So, the question is - what could be causing this kind of situation, with the userbase and the hardware we’re using? Is there anything more specific we should look into? I think our userbase should not warrant emergency situations, but I’m not married to any opinion we’ve had so far, and we’d be very helpful for pointers to what else we could look into. Thanks!

[image] char: This is definitely a memory issue: I’m seeing some huge queries here. Have you rebooted recently? It looks like there are a bunch of idle postgres processes eating a bunch of memory, I think. How much memory did you give postgres in your app.yml? Did you change the defaults? Also, Postgres 13 hasn’t been supported for a year. You really need to upgrade. I didn’t think Discourse would work with PG13 – what version of Discourse are you running?

[image] char: This is definitely a memory issue: I’m seeing some huge queries here. [image] pfaffman: It looks like there are a bunch of idle postgres processes eating a bunch of memory, I think. This doesn’t look like a memory problem to me - there’s only around 6GB taken up by applications. There’s a lot of reading happening, which at a guess I’d say (along with sidekiq being busy) maybe postgres is doing a lot of reading of old data from disk, maybe to do some stats jobs. If the database doesn’t fit in RAM, it’s potentially going to do a lot of reading if that older data is being accessed. That’s what this smells like. USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND admin 2510013 15.8 1.6 7383364 514764 ? SNl 12:55 56:45 sidekiq 7.3.9 discourse [3 of 5 busy] systemd+ 2848301 26.9 25.3 8058104 7806820 ? Rs 17:45 18:18 postgres: 13/main: discourse discourse [local] SELECT systemd+ 2870880 4.3 22.9 8058516 7072000 ? Ds 18:03 2:09 postgres: 13/main: discourse discourse [local] SELECT systemd+ 2875058 21.0 25.4 8101952 7848140 ? Rs 18:07 9:46 postgres: 13/main: discourse discourse [local] UPDATE systemd+ 2924006 30.2 25.3 8112844 7824292 ? Rs 18:44 2:44 postgres: 13/main: discourse discourse [local] UPDATE jystemd+ 2929546 12.8 24.9 8049520 7694404 ? Ss 18:48 0:39 postgres: 13/main: discourse discourse [local] SELECT systemd+ 2931802 17.7 24.5 8045744 7559492 ? Ss 18:50 0:36 postgres: 13/main: parallel worker for PID 946796 systemd+ 2931803 17.7 24.5 8045744 7557568 ? Ds 18:50 0:36 postgres: 13/main: parallel worker for PID 946796 I would look at sidekiq first - I bet it’s busy running updates. Check the /sidekiq url while logged in as admin to see what it’s doing. That’s probably going to show you some long-running update tasks. You can also, on the SQL server: SELECT pid, application_name, query FROM pg_stat_activity WHERE state IS NOT NULL AND state != 'idle'; to see what queries are running and what’s calling them. That’ll hint towards what’s causing the load. Do you have performance headers enabled? You can turn those on and capture them in logs to let you know how much time Discourse is spending on each part.

The kernel swapd has racked up quite a bit of time. It’s quite possible the paging activity wasn’t captured by the short vmstat run. There seem to me to be a lot of postgres processes using more or less 20% of RAM. Too many processes given the available RAM?? Checking the postgresql config would be wise. But a reboot would also be wise before proceeding to re-measure. As the memory percentages add up to much too much, there must be some sharing which isn’t visible. Still, it seems like a lot of large processes. USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND systemd+ 1728387 0.5 24.0 7881244 7423192 ? Ss Jan28 6:55 postgres: 13/main: checkpointer systemd+ 1728388 0.3 21.6 7880688 6669508 ? Ss Jan28 3:47 postgres: 13/main: background writer systemd+ 2848301 26.9 25.3 8058104 7806820 ? Rs 17:45 18:18 postgres: 13/main: discourse discourse [local] SELECT systemd+ 2870879 1.4 15.7 7903276 4854432 ? Ss 18:03 0:42 postgres: 13/main: discourse discourse [local] idle systemd+ 2870880 4.3 22.9 8058516 7072000 ? Ds 18:03 2:09 postgres: 13/main: discourse discourse [local] SELECT systemd+ 2875058 21.0 25.4 8101952 7848140 ? Rs 18:07 9:46 postgres: 13/main: discourse discourse [local] UPDATE systemd+ 2884686 3.3 19.2 7901648 5920344 ? Ss 18:13 1:20 postgres: 13/main: discourse discourse [local] idle systemd+ 2884706 3.4 20.2 8055052 6253836 ? Ss 18:13 1:23 postgres: 13/main: discourse discourse [local] idle systemd+ 2885877 2.4 17.1 8062096 5272220 ? Ss 18:13 0:58 postgres: 13/main: discourse discourse [local] idle systemd+ 2885900 2.3 17.1 7900444 5296948 ? Ss 18:13 0:56 postgres: 13/main: discourse discourse [local] idle systemd+ 2889095 1.9 15.3 8055412 4729620 ? Ss 18:15 0:45 postgres: 13/main: discourse discourse [local] idle systemd+ 2889140 1.8 15.7 7899580 4854332 ? Ss 18:15 0:42 postgres: 13/main: discourse discourse [local] idle systemd+ 2899645 25.6 25.3 8061284 7824768 ? Ss 18:24 7:34 postgres: 13/main: discourse discourse [local] idle systemd+ 2899819 4.4 16.1 7899748 4990744 ? Ss 18:24 1:18 postgres: 13/main: discourse discourse [local] idle systemd+ 2924006 30.2 25.3 8112844 7824292 ? Rs 18:44 2:44 postgres: 13/main: discourse discourse [local] UPDATE systemd+ 2929546 12.8 24.9 8049520 7694404 ? Ss 18:48 0:39 postgres: 13/main: discourse discourse [local] SELECT systemd+ 2931802 17.7 24.5 8045744 7559492 ? Ss 18:50 0:36 postgres: 13/main: parallel worker for PID 946796 systemd+ 2931803 17.7 24.5 8045744 7557568 ? Ds 18:50 0:36 postgres: 13/main: parallel worker for PID 946796

[image] Ed_S: there must be some sharing which isn’t visible Discourse forks after initialisation to benefit from sharing as much as it can, yes.

The situation has improved. We were on 3.6.0, Postgres 13 was working without evident issues - so far. We posticipated the upgrade to 15 because we didn’t have enough free space on the vps, we needed 150GB given our database size. We pruned what we considered useless data - tracking data and search data among all -, performed some routine maintenance on the DB (VACUUM, for instance), upgraded to PSQL15, and upgraded Discourse too, to 2026.2. We don’t know what exactly fixed the issue but we’re doing fine now. The situation seems to be stable now. I’m going to monitor usage metrics for a couple days more. Thanks for your help so far.

Another update, after a few days of normal usage. [image] After the initial spike - I wonder what was going on and I was afraid we wouldn’t have been any closer to a solution - something worked. We don’t know if it was data pruning, updating to PSQL15 or updating to Discourse 2026.1.0, but at least the issue is solved for now. Thanks again.

There were probably background jobs running in sidekiq that needed to complete.

Hi again, I’m updating the thread because something unusual happened, and I’d like some pointers in how to understand what’s going on and how to fix these situations. As I said everything was going smoothly in the last few days. Then something happens. [image] (4d graph) The increase in CPU didn’t happen randomly, it’s tied to this impromptu reboot: [image] (24h graph) Now, our hosting service is starting to disappoint us but random service interruptions can happen, and moving the whole installation would be a lot of work, so we’re going to bear with the situation for now. I’d like to share the 30d graph too, to show how huge this random plateau is [image] The question is, what would you suggest in these cases? Because trying to parse Sidekiq is telling me, at best, that many statistics recalculations are hogging up resources (ie. Jobs::DestroyOldDeletionStubs - 419 seconds; Jobs::AboutStats - 472 seconds; Jobs::EnsureDbConsistency 2083 seconds; Jobs::TopRefreshOlder - 2727 seconds) , and that unexpected reboots are a big issue. But I was hoping the consequences of random reboots would solve themselves within a reasonable number of hours, while it seems that they simply aggravate the current status quo.

From my experience, this kind of CPU behavior is more likely caused by a server infection or security issue, rather than Discourse itself. I’ve run into a similar situation before, and replacing the server eventually solved the problem.

In my opinion, migration is probably necessary. You could set up a new server and install Discourse to test it—if everything runs normally, there’s a high chance the issue is caused by a server infection or security problem. Also, may I ask whether this server has been regularly updated? Has it been a long time since the last upgrade?

This wasn’t in my bingo card, to be honest. We’re on Ubuntu Server 22, there are some minor updates to do, it won’t hurt to force an upgrade now anyway. Let’s see what happens.

Utilisation du CPU anormalement élevée

Assistance produit Installation

supermathie (Michael Brown) Février 2, 2026, 4:23 12

Il y avait probablement des tâches de fond s’exécutant dans Sidekiq qui devaient se terminer.

Sujet		Réponses	Vues
Discourse installation has been getting slower and slower and slower Self-hosting server-resources	36	2335	Avril 15, 2023
Due to extreme load, this is temporarily being shown to everyone... when it's not really the case Self-hosting server-resources	19	2056	Juillet 21, 2023
Discourse Docker HW reserved/used (CPU, RAM, Disk) and how to manage it Self-hosting server-resources	5	991	Mai 16, 2023
Memory creep in last couple of updates Self-hosting hosting	27	3239	Mai 21, 2019
High CPU & Disk Usage After Restore from a Failed Update Self-hosting	14	1101	Mars 30, 2024

Utilisation du CPU anormalement élevée

Sujets connexes