Not milter, but Exim calls ClamAV using the SCAN command when using a UNIX socket, or zINSTREAM for TCP sockets.
I've got 3 'clusters' (loosely coupled groups, more accurately) VMs of differing roles with slightly differing setups here at Loughborough Uni.
-
CentOS 6 MX servers with a small number of custom sig files - consuming around 2GB RAM per clamd instance, scanning around 25-100k messages each per day. ClamAV MaxThreads set to greater than the max permitted number of inbound simultaneous SMTP connections,
with a short pending queue.
-
CentOS 7 MX servers with stock ClamAV sigs - consuming around 1.5GB RAM per clamd instance, scanning around 15-75k messages each per day. ClamAV MaxThreads set to greater than the max permitted number of inbound connections with a small, but a short pending
queue.
-
CentOS 6 MTA (outbound) servers with stock ClamAV sigs - consuming around 2GB RAM per clamd instance, scanning around 25-100k messages each per day. ClamAV MaxThreads set to less than the max permitted number of inbound simultaneous SMTP connections, with a
long pending queue where (pending + active) = max inbound SMTP connections.
Each of these groups are the same in 'hardware' terms - 4 cores, 8GB RAM. They normally don't break a sweat.
>From memory, we had a single instance in the last 12 months where the kernel OOM killer was invoked and killed off clamd after an external 3rd party attempted to exploit a web form on one of our
websites; the form sent several hundred thousand messages via one of the MTA servers which got a touch upset. We never did work out why.
Is that helpful in any way?
Graeme
At this time, we don't have recommendations for those using clamav-milter in conjunction with a mail server under any amount of load. I'd be interested to hear from the community what your experience
has been with real-world milter applications.