In case of memory exhaustion, Cyrus can begin to behave badly. What happens is the master ends up with an incorrect number of available processes, such that it believes there are sufficient workers to handle the incoming connections, when in fact there are not. The easiest way to check this is to look at those times when you see failed connections, and look to see if you've had any memory bottlenecks shortly before then. If you see any problems with memory exhaustion, it's generally a good idea to restart the cyrus server. (If you're daring, you can attach to it with a debugger and manually modify the Services[] array, but that's a bit dicey...)
Michael
--On Tuesday, June 10, 2003 10:51:19 -0400 John Straiton <[EMAIL PROTECTED]> wrote:
Funny that I haven't found much in the lines of tuning suggestions for Cyrus on googlegroups or in the info-cyrus archives but I think I may be in need of it. I'm using a 4.8-STABLE FreeBSD machine, Dual 600Mhz with 1.5GB of RAM and plenty of RAID5 space.
We use Cyrus+Postfix+AMAVISd+SpamAssassin and are rather happy with the combination. Our postfix feeds 5K addresses into 4K cyrus mailboxes. Load on the machine usually rides between 0.5 and 1.0. top normally reports around 60%-70% idle levels. In normal operations, I'll see around 30-50 connections to the server at all times since most of our users use pop3. We also limit mailboxes to no more than 25MB other than employees. All employees use IMAP tho'. Our entire message store only contains 5.6GB of messages.
The problem I'm having started about 2 days ago when our Nagios monitoring started reporting that connectivity to the server (pop3/imap) was failing. Then we'd get recovery notifications immediately after. Kinda like the server was only unable to handle itself for a brief moment and then would get back to business. I also personally noticed that I'd get notifications in Outlook that some of the 5 IMAP connections I keep to the server would time out periodically. I would assume since send/receives occur every 5 minutes that these are not idle timeouts.
This has never been a problem before, but obviously with a company that's still growing, every day we have more users on the system than the day before. I fear that something on the machine or in cyrus' configuration is holding us back.
I come seeing suggestions for things I could check or change in order to resolve this before it gets to being more of a problem than it is. I figured I'd start with Cyrus and then move down to the OS level.
Thanks, John Straiton [EMAIL PROTECTED] Clickcom, Inc 704-365-9970x101
