-------------------------------------------------- From: "Steve Chupack" <steve.chup...@dealer.com> Sent: Saturday, September 19, 2009 3:52 PM To: <courier-imap@lists.sourceforge.net> Subject: Re: [Courier-imap] long running imapd processes
> Thanks. I suspected this was the case. I had someone tell me it was bad, > so I figured I'd check with the experts. > > I am dealing with some performance issues, but we typically have approx > 600 imapd processes running on a 3 year old, quad core box. Also, we have > numerous users with 20K plus messages in their inbox, and rumor has it > that 10K or so is pushing it. > > Anyone have an opinion on that last tidbit? Sure - depends on filesystem, number of users, number of simultaneous users, etc. - watch io wait in top. We have 2 server cluster with Maildirs on NetApp 2020 filer over nfs and 600-700 connections at any time. The problem with number of messages shows up in webmail more - anything more than 2,000 is slow. With full client like Thunderbird - 10,000 is workable in our case. The problem is readdir over nfs (I think). Bulk of our nfs operations is from reading and re-reading Maildir contents. So, the answer is (as always) - it dedpends.... > > Thanks again for the helpful reply. > > Steve > > > > On Sat, 19 Sep 2009 13:41:58 -0400 > Sam Varshavchik <mr...@courier-mta.com> wrote: > >> Steve Chupack writes: >> >> > Running top on my courier-imap box frequently/consistently shows >> > numerous imapd processes with a Time value of many hours. I'm having a >> > friendly debate with some fellow admins about whether this is bad. >> > >> > One opinion is that imapd processes should never last more than a few >> > seconds before they terminate, but I'm not so sure. I'm thinking these >> > processes may simply result from clients that keep a persistent IMAP >> > connection. >> >> All IMAP connections are persistent. POP3 connections are short lived, >> while >> IMAP is specifically designed to be a persistent protocol, with long >> running >> sessions. >> >> > I should add that these processes are in a sleep state the vast >> > majority of the time. >> >> Correct. So, what's the issue? >> >> > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register > now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Courier-imap mailing list > Courier-imap@lists.sourceforge.net > Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap > ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Courier-imap mailing list Courier-imap@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap
