On Thu, Dec 9, 2010 at 12:58 PM, Timo Sirainen tss@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).