Le 04/04/2013 13:23, Ludovic Marcotte a écrit :
On 04/04/13 05:00, Thibault Le Meur wrote:
I've had the same issue sometimes on squeeze, x64, SOGo 2.0.4b.
Rebootting the server was the only way to get back to a working SOGo.
You just loose evidences by doing this.
Yes I know, but sometimes getting quickly back in a working mode is more
important :( It's the balance between resolving problems and incidents ;-)
There are two possibilities for SOGo using 100% CPU:
1. the *parent* process is trying to find a free child and all of
them are busy because of slow subsystems (LDAP, database, IMAP
server, SMTP server or even remote HTTP servers for remote ICS
subscriptions). If all children are busy, the parent process will
spin so quickly it'll consume 100% CPU, appearing stuck, while it
isn't ;
2. a *child* process has gone awry because of a broken subsystem or a
bug in the code. Most of the time, it's due to unhandled IMAP
"traffic" (abrupt connection close due to server bugs, broken
server responses, broken mails not passed by correctly by the
server, etc.). The IMAP code should be more resilient to this, but
sope-mime is just horrible, and should eventually be replaced by
the much cleaner Pantomime framework.
1. can be tuned quite easily, by carefully increasing the workers limit.
Thanks for the advice. I've seen in this list the following proposals:
sudo -u sogo defaults write sogod SxVMemLimit 1024
sudo -u sogo defaults write sogod WOWorkersCount 32
I just don't feel like this kind of setup is really safe... couldn't it
result in a very high memory consumption mode ?
2. is a bug. When it happens, simply attach to the *child* process and
produce a stack trace. Then, file a bug report with all the relevant
data, including the culprit email message (which can be found in the
sogo.log file). All of this is documented here:
http://www.sogo.nu/english/nc/support/faq/article/how-do-i-debug-sogo.html
Okay, I'll try this next time.
Thanks again for your useful tips,
Thibault
--
[email protected]
https://inverse.ca/sogo/lists