[clamav-users] About clamav's requirements for system resources

Micah Snyder (micasnyd) micasnyd at cisco.com
Tue Nov 6 20:35:21 UTC 2018


Thanks Graeme,

That is helpful.  I'm definitely not familiar with how to use Exim with ClamAV.  I had been hoping to set up a page on how to integrate ClamAV with other applications.  Putting details from this at the top of a guide for Exim would be useful.  If you have the time to do a short write-up on the setup for Exim that'd be pretty sweet.

The same applies to anyone else using ClamAV with other applications.  We'd really love your help documenting how to get new users started.

-Micah

Micah Snyder
ClamAV Development
Talos
Cisco Systems, Inc.


On Nov 5, 2018, at 12:12 PM, Graeme Fowler <G.E.Fowler at lboro.ac.uk<mailto:G.E.Fowler at lboro.ac.uk>> wrote:

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



From: clamav-users <clamav-users-bounces at lists.clamav.net<mailto:clamav-users-bounces at lists.clamav.net>> on behalf of "Micah Snyder (micasnyd)" <micasnyd at cisco.com<mailto:micasnyd at cisco.com>>
Reply-To: ClamAV users ML <clamav-users at lists.clamav.net<mailto:clamav-users at lists.clamav.net>>
Date: Monday, 5 November 2018 at 15:14
To: ClamAV users ML <clamav-users at lists.clamav.net<mailto:clamav-users at lists.clamav.net>>
Subject: Re: [clamav-users] About clamav's requirements for system resources

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.


_______________________________________________
clamav-users mailing list
clamav-users at lists.clamav.net<mailto:clamav-users at lists.clamav.net>
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clamav.net/pipermail/clamav-users/attachments/20181106/1093e80d/attachment.htm>


More information about the clamav-users mailing list