Hello

Am 20.04.21 um 21:36 schrieb Kevin Creechan
(kevincreec...@ibcbrantford.com):
> I have a server with 50GB RAM. It usually sits around 13-14gb used on
> any given day.
> 
> Recently the server has become unresponsive and I've had to keep my eye
> on it to see what's going on.
> 
> Before the server falls over, htop shows that the topmost processes
> using memory are SOGO worker processes. There's 5-6 of them all showing
> 7.3% and have been running for more than 12 hours. Over time I'll see
> another, and another, until memory is exhausted and the server is
> unresponsive.
> 
> Killing these processes brings it back to the normal 13-14gb used.
> 
> I'd like to know if there is any way to see why these particular
> processes are sticking and which users may be having the problem. Any
> way of finding this out?
> 

You only can activate additional debugging output.
With
    SOGoDebugRequests = YES;
you get an entry when SOGo starts processing a request and a summary how
long it took like this:

Apr 19 10:34:41 sogod [1034]: |SOGo| starting method 'GET' on uri
'/SOGo/so/WhatEverUser/Calendar/view'
Apr 19 10:34:41 sogod [1034]: |SOGo| request took 0.037421 seconds to
execute
Apr 19 10:34:41 sogod [1034]: 134.34.1.48 "GET
/SOGo/so/WhatEverUser/Calendar/view HTTP/1.1" 200 9401/0 0.040 31037 69%
0 - 18

In angle brackets you get the pid of that process.
The "|SOGo| starting method..." gives you the URL with username/email of
that request.

Beware, you will get 3 instead of 1 line for every request.
Therefore make sure you have enough space on your log device.
Also changing Debug output requires a restart of sogo.

> Also, with the SvMemLimit set to 500MB, why would these processes not be
> auto-killed?  (I can see in the log that the majority of these processes
> are being restarted when they hit 500MB, but these particular ones don't)
> 

For that you have to know, how those limits work.
SOGo main process accepts a connection and distributes that request to a
free worker.
That SOGo worker processes that request.
While doing so the SOGo WatchDog process will monitor the worker.
WatchDog will kill the worker if either it does not respond anymore, or
if WOWatchDogRequestTimeout is reached.
After finishing the request, the worker is checked from the WatchDog, if
they use more memory than the set SvMemLimit limit.
If yes, they are killed and a new worker is spawned.

Therefore they can get as big as your RAM + swap allows, as long as they
process one request, answer timely to WatchDog and don't take longer
than WOWatchDogRequestTimeout (in Minutes).


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