RE: Tuning Suggestions
> > 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. > > One thing you might want to try is to use /dev/urandom > instead of /dev/random for SASL on your system (recent > versions have a --with-devrandom configure switch, otherwise > you need to edit config.h). > > Additionally, you may want to increase the number of > preforked processes, but this will only allow you to prevent > larger spikes of activity from affecting you adversely, it > won't help if the load is sustained at a higher level. Since it was simplest, I started with the preforking. I set it to an arbitrary number of 10. Here's the good news. It works. No more broken IMAP connections. I'll try that recompile as well as time allows but I thought I'd let everyone know that for today, that got it working smooth again. Thank you kindly for the suggestions John
Re: Tuning Suggestions
I can't tell precicely from your report, but it may have something to do with a problem we've seen several times. 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
Re: Tuning Suggestions
On Tue, 10 Jun 2003, John Straiton wrote: > 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. One thing you might want to try is to use /dev/urandom instead of /dev/random for SASL on your system (recent versions have a --with-devrandom configure switch, otherwise you need to edit config.h). Additionally, you may want to increase the number of preforked processes, but this will only allow you to prevent larger spikes of activity from affecting you adversely, it won't help if the load is sustained at a higher level. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Tuning Suggestions
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
