Either my Xen DomU gets slower or my MTA keeps getting busier. But when looking at the stats I could see that a lot of clamscan have been spawned on every fetchmail. Nothing unusual, this is how it always worked. But to be honest, the setup was rather inefficient, to say the least: for every incoming mail, maildrop spawns a
clamscan process, sometimes more than one in parallel. ps(1) shows, for just one process:
PID %MEM RSS SZ VSZ COMMAND 8749 12.8 164500 49081 196324 clamscanSo, one process needs 12.8% of the systems memory, with just 5 process we're at 64% - and the box was indeed swapping heavily. So I finally got around *) to move the virus-scanning to Exim and let it speak to
+av_scanner = clamd:/var/run/clamav/clamd.ctl
+ warn + message = X-Virus-Status: Infected + demime = * + malware = *Note: I chose warn over deny here - I still want to have those viruses, I just want to have it annotated :-)
User clamav AllowSupplementaryGroups true LocalSocketGroup Debian-exim LocalSocketMode 0660For Debian/5.0, I also had to:
# usermod -G Debian-exim clamav # mkdir -m0770 /var/spool/exim4/scan # chown Debian-exim:Debian-exim /var/spool/exim4/scanWith all this in place (plus disabling the clamscan directives in
.mailfilter), the box is far less loaded now. According to
ps(1), our single
clamdnow goes sometimes up to 16%, but that's still just one process and better than those >60% before.
Btw, if you want to test your email AV setup and your mailprovider doesn't even allow the sending of the Eicar Test File, try this instead.
Update: And it helped indeed, see the loadavg going down after changing the configuration to use
clamdnow. Phew, now I wonder why I haven't done this earlier....
*) I hate MTA configurations, I really do :-\