On Thu, Dec 9, 2010 at 12:58 PM, Timo Sirainen <t...@iki.fi> wrote: > On Thu, 2010-12-09 at 10:18 -0800, Mark Moseley wrote: > >> Upping the client_limit actually results in less processes, since a >> single process can service up to #client_limit connections. When I >> bumped up the client_limit for imap, my context switches plummeted. >> Though as Timo pointed out on another thread the other day when I was >> asking about this, when that proc blocks on I/O, it's blocking all the >> connections that the process is servicing. > > Yeah. And it's even worse if it's blocking on waiting for a lock. > > BTW. Do you have these kind of error messages in your log: > > net_connect_unix(pop3) failed: Resource temporarily unavailable > net_connect_unix(imap) failed: Resource temporarily unavailable > > I think those are sometimes happening when not using client_limit=1, > because all the processes are busy at that time and can't accept a new > connection (while with client_limit=1 a new process would be created to > handle it).
Yeah, I do get small bursts of those, but not enough to get too worried about. I was assuming it was hitting process_limit for imap. On one box, for all of today I see two clusters of those errors, both lasting about 15-20 seconds apiece. The problem is that the smaller I set client_limit (including =1) on imap, the more likely the mass of imap processes will push these box into swap (and these are old 2gig boxes; hoping to get replace them soon with newer Dells, like PE 450's).
