Clamav suggestions

[Richard Frovarp]

Arto wrote:
> Arto wrote:
>> Richard Frovarp wrote:
>>> Arto wrote:
>>>> Richard Frovarp wrote:
>>>>> Arto wrote:
>>>>>> Richard Frovarp wrote:
>>>>>>> Fabio Pedretti wrote:
>>>>>>>>
>>>>>>>> 3) Support for clamd trough clamdscan is nice, however, best 
>>>>>>>> would be to connect to clamd directly to its socket (or network 
>>>>>>>> socket) from MailScanner, without call clamdscan, and fallback 
>>>>>>>> to clamscan if clamd is not working. 
>>>>>>>
>>>>>>> Why not just run clamavmodule? From my understanding, the 
>>>>>>> support for clamd was added so that those that didn't want to 
>>>>>>> keep up with the Perl module required for clamavmodule would 
>>>>>>> have something faster than clamscan. Any direct call to clamd 
>>>>>>> from MailScanner would require a Perl module, so at that point 
>>>>>>> you're losing the requirements benefit of running clamd.
>>>>>>
>>>>>> FYI, we have used all of those during last three weeks. First 
>>>>>> clamav (indeed about two year before this period), then 
>>>>>> clamavmodule and during this week clamd.
>>>>>>
>>>>>> Our MX server passes normally about 10k mails/day (MS, postgrey, 
>>>>>> postfix and SA) and clamd is IMHO the most comfortable as regards 
>>>>>> load, memory and swap. The server is a vmware client (CentOS4.4 ) 
>>>>>> with 2 x 2,4 GHz and 775 Mb memory reserved to client. After 
>>>>>> start the swap is with clamd under 40 Mb and it will remain 
>>>>>> there. With clamavmodule and clamav the swap varies from 40 to 
>>>>>> 400 Mb and the load can be even over 20 with clamav.
>>>>>>
>>>>>> More details from our Cacti stats:
>>>>>> http://www.artio.fi/.component/imageGenerator.php?fileName=%2Fwebroot%2Fweb%2Ffocus%2Fwww%2Fimnetti%2Fmedia%2F0%2F10841.png&cache=1&cachePrefix=.cache 
>>>>>>
>>>>>> The first week was runned with clamav till midday of thursday, 
>>>>>> after that with clamavmodule and this week with clamd.
>>>>>>
>>>>>> With numbers this week (four workdays because of free Monday, 
>>>>>> otherwise typical):
>>>>>>
>>>>>> received: 33307
>>>>>> spam: 836
>>>>>> rejected: 163033
>>>>>> virus: 5
>>>>>> bounced: 150
>>>>>> sent: 8331
>>>>>>
>>>>>> -arto
>>>>>>
>>>>>
>>>>> You may want to decrease the number of MailScanner processes 
>>>>> running under Max Children. I've got a vmware guest with 1 GB of 
>>>>> RAM. The host is a dual socket dual core 3.2 GHz Xeon. We're not 
>>>>> see any swap at all running clamavmodule. However, I have Max 
>>>>> Children set to 7. This particular scanner handles internal mail 
>>>>> only and scan times are only a couple of seconds during the middle 
>>>>> of the day with batch sizes of 1 or 
>>>>
>>>> Max Children = 10 (which should be the recommended value with 2 
>>>> processors.)
>>>>
>>>> -arto
>>>>
>>> That's assuming you have the RAM. Each of mine are about 80 MB in 
>>> size, 10 of those would be 800 MB, which is more than you have 
>>> allocated for RAM.
>
> And sure I mean about 54 Mb. :-)
>

If you aren't actively swapping (to check: vmstat 5) it probably isn't a 
big deal. If you are actively swapping, back it off some. Other 
processes on the box also need memory. You'll get greater performance 
from fewer children and no swapping than greater children and some 
swapping.