After updating to Discourse 2.2, peternlewis noticed high CPU usage alerts, likely due to image conversion tasks triggered by a one-time post rebaking process. Others, including pfaffman and Stephen, explained that this is expected behavior and suggested reducing the rebake old posts count setting (default: 80) to 20 to lessen CPU load duration — though this extends the total processing time. michaeld clarified that lowering the count reduces peak duration, not intensity. pfaffman and sam reassured that the system prioritizes critical services over image processing, and unless users report performance issues, the high CPU usage is harmless — it’s what servers are designed for. peternlewis confirmed no visible performance degradation but was concerned about sustained alerts; Stephen and pfaffman emphasized that the process won’t overlap or cascade, and no immediate action is needed unless users are impacted. pfaffman noted that the need to adjust settings was temporary and no longer necessary in current versions.
It defaults to 80 and is usually fine at this value but the one-time operation introduced as a part of 2.2 does stress more resource-constrained systems.
You only need to lower it when you see it constantly at high CPU. It will keep peaking at 100% then going back to normal etcetera.
Lowering the count will only make the peaks less wide (i.e. shorter in time), not less high. It will also make the entire process take 4x as long.
And it may be that the way that it works now there is no performance hit for the high cpu. @peternlewis did you experience performance issues or just notice the high cpu? If it was the latter, then you’d likely not want to change the default.
I noticed a constant stream of alert notifications of high CPU for more than 5 minutes. I did not notice any particular performance issues with the forum, but then I might not even if there were some - others might notice issues without me noticing anything. What I noticed was many monitor alerts of abnormally high CPU usage.
Since these alerts required high CPU usage for at least five minutes, I would presume that with the setting as it was it was spending more than five minutes out of every 15 at high CPU which seems dangerously close to continuous high CPU usage and perhaps ending up with the system starting the next batch before finishing the previous batch depending on how it is implemented, which could then lead to a cascade performance failure. Unless the 15 minute in the preference does not start counting until the end of the batch…
No it won’t end up overlapping like that. As people have pointed out in the other topic you can just make the number smaller and have it take longer. The world won’t end if the reprocessing isn’t done immediately.
In that case, you probably didn’t need to do anything. When these changes were first made some people experienced delays in notifications because the sidekiq queue was full of images getting reprocessed, but I am pretty sure that’s no longer the case. It’s really not a problem if your computer has to work hard. It’s what we pay them for, after all.
I did a lot of work making this rather expensive process as seamless as possible, we have the operating system de-prioritize all the image magick convert jobs so it loses out when CPU is asked for and other processes like the DB, Redis or Forum need it.
That’s what I thought. I think that there was a 3-6 day window when “reduce rebake old posts count” was a good idea, but then realized that it’s no longer necessary. I just hope I can find all the places that I changed it.
