Hello Am 21.03.25 um 16:16 schrieb Daniel Kollmer ([email protected]):
Hello allI currently run Version 5.11.2 (@65536ba7a376 202503180650) and we have observed extreme peaks in CPU load and memory use. After a large number of twekas (I have posted them here before) the problem persists with Sogo now triggering the oomkiller. In the past we had found through SQL queries that the extreme peak in memory use was caused by a calendar which somehow had managed to have re-ocurring events going back to the 17th century, we guessed it must have been an error in a user entry.Now I have kept the logs and investigated what the last queries were that happened before the peaks, but they did not appear to trigger anything unexpected.I wonder what I could do to find the cause of these peaks. It appears to run at very good performance throughout, but then, approximately once every one or two days something triggers a peak that causes a complete meltdown.Do any of you have suggestions on what to do?
We had that too. The cause was the database got very slow. Therefore the workers piled up in high access times, using up all space. We have a separate database server, which is not only used for SOGo. We fixed that slow database.While doing so, we prevented oomkiller from killing the sogo main process with:
# echo -100 >/proc/$(cat /var/run/sogo/sogo.pid)/oom_score_adjThis only prevents the oomkiller from killing the main process any other worker will eventually get killed.
This means one user will get no response.But there is a watchdog, which detects such killed worker processes and starts a new one (with less RAM usage).
Beware: * You have to set this after each start of sogo, as the process-id changes. * It is not a silver bullet. Better fix the reason. Kind regards, Christian Mack -- Christian Mack Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung, Lehre, Infrastruktur 78457 Konstanz +49 7531 88-4416
smime.p7s
Description: Kryptografische S/MIME-Signatur
