On Fri, Aug 13, 2004 at 04:07:47PM -0700, Jim Gaynor said: > It isn't sendmail that's borking this system, tho; it's the multiple > high-load high-memory clamav-milter processes. I've checked the sendmail > queue when those processes start to hog resources, and only had 32 items > in queue one time, 24 another. Heck, right now I have 26, and load is > still < 1.0 > > I'm not saying your approach is wrong, I'm just saying I'm not entirely > convinced it's right - spawning off more children doesn't seem the > answer when the existing ones appear to have all gone into > high-resource-consumption state...
No, you're reading me backwards. It is the clamav-milter child threads killing the system. However, adding senmail processes stuck in a wait state to that only makes it worse. Get rid of the max-children in clamav-milter, and control the overall scene by reducing the number of sendmail -> milter processes spawned in sendmail. Doing it in the milter just adds choke to sendmail. This is what I have found most effective in (fairly) high-load mail systems, meaning 50-100,000 emails a day, where we do both clam and spamassassin scanning. It's better to delay the startup of a new sendmail -> clam -> whatever process, than to start up the transaction, and keep it waiting around longer because the system is resource starved. YMMV. -- -------------------------------------------------------------------------- | Stephen Gran | BOFH excuse #221: The mainframe needs | | [EMAIL PROTECTED] | to rest. It's getting old, you know. | | http://www.lobefin.net/~steve | | --------------------------------------------------------------------------
pgpzKDL6aTON2.pgp
Description: PGP signature
