General discussion on installation and configuration of SOGo

Text archives Help

Re: [SOGo] Re: just gone live with sogo, and keep getting 100% cpu usage... :-(

Chronological Thread 
  • From: Thibault Le Meur < >
  • To:
  • Subject: Re: [SOGo] Re: just gone live with sogo, and keep getting 100% cpu usage... :-(
  • Date: Thu, 04 Apr 2013 17:22:06 +0200

Le 04/04/2013 13:23, Ludovic Marcotte a écrit :
" type="cite">
On 04/04/13 05:00, Thibault Le Meur wrote:
" type="cite">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 ;-)

" type="cite"> 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 ?

" type="cite">
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:

Okay, I'll try this next time.

Thanks again for your useful tips,

Archive powered by MHonArc 2.6.18.

Top of page