Re: [SOGo] terminating app, vMem size limit …
Am 06.02.24 um 17:09 schrieb Christian Mack (christian.m...@uni-konstanz.de): Hello Am 06.02.24 um 13:41 schrieb Frank Richter (frank.rich...@hrz.tu-chemnitz.de): Hi, we’ve set SxVMemLimit = 768; in /etc/sogo/sogo.conf But it seems that this big value isn’t sufficient, we see this several times a day in sogo.log: Feb 06 04:47:06 sogod [1280936]: 2003:f3:1708:b0ca:f955:2664:d05:4987 "GET /SOGo/so/dadel/Mail/0/view HTTP/1.1" 200 427415/0 1.657 - - 39M - 20 Feb 06 04:47:06 sogod [1280936]: |SOGo| terminating app, vMem size limit (768 MB) has been reached (currently 771 MB) ax_Main;" ^ [...] Feb 06 04:47:06 sogod [1280926]: <0x0x5606e7615030[WOWatchDogChild]> child 1280936 exited What is advisable? We don’t like to raise SxVMemLimit even more … They will always happen. But such worker/child termination is only happening *after* a request was processed. Therefore they are usually harmless. The only drawback is the time needed to start a new worker/child. While this is happening, you have less worker available. Therefore you only have to keep an eye on how often this happens. As long as it only happens a couple of times per hour, you are save. Thanks, Christian, for clarifying this. I’ll look into memory consumption of the SOGo processes, and maybe revert to 512 MB. BTW: We use SxVMemLimit = 512; with 350 worker With approx. 20,000 accounts => approx. 1.2 million requests per day => approx. 600 of the above terminating errors per day We have 9,500 users , use 2 servers with each 16 GB RAM and 50 SOGo workers, ~ 500,000 requests per work day on each server. Frank -- Frank Richter, Chemnitz University of Technology, Germany
Re: [SOGo] terminating app, vMem size limit …
Hello Am 06.02.24 um 13:41 schrieb Frank Richter (frank.rich...@hrz.tu-chemnitz.de): Hi, we’ve set SxVMemLimit = 768; in /etc/sogo/sogo.conf But it seems that this big value isn’t sufficient, we see this several times a day in sogo.log: Feb 06 04:47:06 sogod [1280936]: 2003:f3:1708:b0ca:f955:2664:d05:4987 "GET /SOGo/so/dadel/Mail/0/view HTTP/1.1" 200 427415/0 1.657 - - 39M - 20 Feb 06 04:47:06 sogod [1280936]: |SOGo| terminating app, vMem size limit (768 MB) has been reached (currently 771 MB) ax_Main;" ^ [...] Feb 06 04:47:06 sogod [1280926]: <0x0x5606e7615030[WOWatchDogChild]> child 1280936 exited What is advisable? We don’t like to raise SxVMemLimit even more … They will always happen. But such worker/child termination is only happening *after* a request was processed. Therefore they are usually harmless. The only drawback is the time needed to start a new worker/child. While this is happening, you have less worker available. Therefore you only have to keep an eye on how often this happens. As long as it only happens a couple of times per hour, you are save. BTW: We use SxVMemLimit = 512; with 350 worker With approx. 20,000 accounts => approx. 1.2 million requests per day => approx. 600 of the above terminating errors per day 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
[SOGo] terminating app, vMem size limit …
Hi, we’ve set SxVMemLimit = 768; in /etc/sogo/sogo.conf But it seems that this big value isn’t sufficient, we see this several times a day in sogo.log: Feb 06 04:47:06 sogod [1280936]: 2003:f3:1708:b0ca:f955:2664:d05:4987 "GET /SOGo/so/dadel/Mail/0/view HTTP/1.1" 200 427415/0 1.657 - - 39M - 20 Feb 06 04:47:06 sogod [1280936]: |SOGo| terminating app, vMem size limit (768 MB) has been reached (currently 771 MB) ax_Main;" ^ :1: element span: validity error : ID MathJax-Span-32 already defined > ^ :1: element span: validity error : ID MathJax-Span-33 already defined " id="MathJax-Span-33" style="font-family: MathJax_Main; padding-left: 0.222em;" ^ :1: element span: validity error : ID MathJax-Span-34 already defined 4" style="font-family: MathJax_Math; font-style: italic; padding-left: 0.222em;" ^ :1: element span: validity error : ID MathJax-Span-35 already defined d:1: element span: validity error : ID MathJax-Span-36 already defined ="font-family: MathJax_Main;">(:1: element span: validity error : ID MathJax-Span-37 already defined "mi" id="MathJax-Span-37" style="font-family: MathJax_Math; font-style: italic;" ^ :1: element span: validity error : ID MathJax-Span-38 already defined s="mn" id="MathJax-Span-38" style="font-size: 70.7%; font-family: MathJax_Main;" ^ :1: element span: validity error : ID MathJax-Span-39 already defined > ^ :1: element span: validity error : ID MathJax-Span-40 already defined :1: element span: validity error : ID MathJax-Span-41 already defined "mi" id="MathJax-Span-41" style="font-family: MathJax_Math; font-style: italic;" ^ :1: element span: validity error : ID MathJax-Element-6-Frame already defined t;/mimo stretchy=false)/mo/math" role="presentation" ^ :1: element span: validity error : ID MathJax-Element-7-Frame already defined org/1998/Math/MathMLmix/mi/math" role="presentation" ^ 2024-02-06 04:47:06.864 sogod[1280926:1280926] INFO(-[NGActiveSocket isAlive]) poll(): fd=23 revents=0x0011) Feb 06 04:47:06 sogod [1280926]: <0x0x5606e7615030[WOWatchDogChild]> child 1280936 exited What is advisable? We don’t like to raise SxVMemLimit even more … Thanks Frank -- Frank Richter, Chemnitz University of Technology, Germany
