Server seemed stuck till I killed clamscan/spamassassin

Running ISPConfig 2.2.16, our email server had came to a crawl today, to the point it was virtually stopped. A reboot did not work, and as soon as the lines stating that email services were starting (starting courier, starting postfix, etc), it was at this point that the server seem to almost die.

It was by luck that when I switch over to tty2 and logged in, I was able to run a top command, and found a ton of clamscan processes running. I took the chance that all of the email was clean and ran:

killall clamscan

And then ran:

killall spamassassin

I had to repeat this procedure a dozen times or so before the queue had cleared out. At this point, the server was now responsive, and behaving as it should. Currently, it is properly checking mail with clamscan and spamassassin.

I do remember a bug back in ISPConfig version 2.2.10 where the clamscan process (v0.90 something) would hang, showing 99% CPU usage, or split evenly between two users (50-50%). This was at another client, and the fix at that time was to upgrade to 2.2.15 or so.

Is there a way to prevent this slowdown, which I assume to be a stuck queue, in the future. Is there a way to check the logs to see where it may have become stuck?

Thank you in advance for any and all replies. I am considering upgrading from 2.2.16 to 2.2.17 in the hopes this may fix/prevent the issue. But I noticed no bugs were reported about any slowdowns/queues.


edit: Running ubuntu server 7.04, used tutorial for perfect ISP for install. First installed version was 2.2.16

 

Very quick reply. Thanks, I'll dial in tonight and make the modifications, providing the client allows this.

One thing I did do to help prevent this is add a few RBL rules to postfix:

reject_rbl_client sbl-xbl.spamhaus.org,
reject_rbl_client bl.spamcop.net,
reject_rbl_client cbl.abuseat.org,
reject_rbl_client relays.ordb.org,
reject_rbl_client opm.blitzed.org,
reject_rbl_client dnsbl.njabl.org,
reject_rbl_client blackholes.easynet.nl

This would help filter emails before clamassassin and spamassasin even has a chance to look at this. I can already see a difference in the CPU usage.