Hello

Am 23.04.20 um 15:31 schrieb Thomas Winterstein
(thomas.winterst...@rz.uni-augsburg.de):
> Hello
> 
>>> Hi folks,
>>> I'm getting this log message: terminating app, vMem size limit.
>>>
>>> Aug 30 07:36:40 sogod [20709]: |SOGo| terminating app, vMem size
>>> limit (384 MB) has been reached (currently 389 MB)
> 
>>> Using default value 384MB, should I increase this value on sogo conf?
>>>
>> It depends.
>> You will always get some of these log entries.
>> Worst case would be, that after every request SOGo starts a new worker.
>>
>> You can reduce their number by increasing SxVMemLimit.
>> But you will also increase your RAM usage.
>> If you have enough RAM left even for peak load, then increase it.
> 
> We also have a lot (~500 a day) of these log messages on our server.
> Maybe just recently, maybe for a longer time. Our settings are:
> 
> WOWorkersCount                         = "50";
> WOListenQueueSize                      = "10";
> WOWatchDogRequestTimeout               = "60";
> SxVMemLimit                            = "512";
> 
> Preceding lines before the child processes get terminated:
> 
> Apr 23 07:24:21 sogod [27093]: ... "GET
> /SOGo/dav/user/Calendar/personal.ics HTTP/1.1" 200 49746/0 20.191 245196
> 79% 625M
> Apr 23 13:17:26 sogod [16168]: ... "GET
> /SOGo/dav/user/Calendar/personal.ics HTTP/1.1" 200 755747/0 7.949 - - 250M
> 
> Are these request sizes normal?
> 

These entry are someone downloading her complete personal calendar
read-only per ics-URL.
I would suggest to check her configuration.
Usually she should not use the ics URL to access her calendar, but the
calDAV one.
I suspect she can not change anything in that calendar from that
device/client.
With real calDAV access her downloads will be significantly smaller and
faster, especially with client side caching.

That said, 625M for a calendar looks huge to me.
How old is that calendar?
Do you delete old entries from users calendars?
Check "sogo-tool truncate-calendar"

> Am I right in the assumption, that child processes get occupied during a
> request and afterwards get freed again? 

No, their used memory gets not freed.
They keep their till then used memory, but reuse it for the next request.
Therefore they grow in memory usage when a bigger request comes in.
And they keep that size, till an even bigger one comes in.
The WatchDog checks them after each request, if they occupy more than
the set limit.
If they do, WatchDog tells them to end themself, and starts another worker.

> And with 50 workers * 512 MB
> Memlimit wouldn't that in theory be 25 GB that could get used?
> 

Almost.
There is a part of that memory shared between all workers.
That gets counted for each worker, but does only exist once.
I can not give you an exact number of how big that part is.

And all workers would have to get requests one Byte below the mem limit,
in order to not get killed by the WatchDog.
That is not very likely :-)

> We have a few hundred daily users on the server, but the RAM is far from
> full with 1,5-3 GB used of 8 GB. What are benchmark values of these
> settings with our amount of users/RAM (excluding EAS users)?
> 

As I said, that depends on the size of calendars, mail folders and
address books of that users.
It also depends on what they do.
When they access their accounts a lot with ics-URLs, write and receive
huge emails or zip their mail folders a lot, they will get your machine
to its limits easily.


Kind regards,
Christian Mack

-- 
Christian Mack
Universität Konstanz
Kommunikations-, Informations-, Medienzentrum (KIM)
Abteilung IT-Dienste Forschung und Lehre
78457 Konstanz
+49 7531 88-4416

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to