No I don't think it's normal. What are you doing in your plugins? Wasn't there some issue we uncovered a while ago to do with MySQL?
I don't recall hearing of issues with mysql.. we use postgres here and do, well, lots of stuff: lookups for for global and ip-based max concurrency rules in hook_pre_connect, lookups for various preferences in hook_rcpt.. if it's a plugin that's breaking things then it's almost certainly our own code, as we've re-written most of qp's plugins for our uses :)
Any clue what's going on in general? Do children wind up 'orphaned' when they go completely unresponsive, e.g. they're hanging out in some infinite loop somewhere or something similarly evil?
The basic problem we've been encountering is that very rarely, all of our dozen QP nodes inexplicably introduce long delays before answering with a banner (no banner delay involved); watching the logs, it doesn't look like any child is spawned during this wait, and we aren't anywhere near max-children. Eventually, a child is spawned and then handles the connection normally, assuming the client hasn't timed out. And eventually, every slave recovers and starts behaving normally. It seems like this issue would have to be network related in some way, as every node is affected around the same time; DNS was the first obvious choice but we don't seem to be having any problems with that. One we find said network problem this issue might go away, but it seems that our smtpd should not be so fragile to whatever issue is hanging it up..
-Jared Inbound and outbound email scanned for spam and viruses by the DoubleCheck Email Manager v5: http://www.doublecheckemail.com
