Upgrade to clamav 0.90.2 makes scanning extremely slow

Scott Silva ssilva at sgvwater.com
Fri Apr 27 00:23:37 IST 2007


Richard Lynch spake the following on 4/26/2007 2:26 PM:
> DAve wrote:
>> Richard Lynch wrote:
>>> Julian Field wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> What's wrong with just using clamavmodule? You need to use
>>>> Mail::ClamAV 0.20 with ClamAV 0.90 and later, which is all included
>>>> in my ClamAV+SA package.
>>>>
>>>> I don't understand the sudden rush to clamd at all. Can someone
>>>> explain to me please?
>>>>
>>>> Jules.
>>>>   
>>> The only advantage I see is that it's all maintained by a single
>>> source.  That is, the ClamAV team maintains clamd and clamdscan
>>> together.  There's no third party perl package that may not be up to
>>> date.  I don't know if there's a performance improvement one way or
>>> the other.  It's conceivable that clamdscan/clamd performs better in
>>> a multiprocessor environment by spreading the load across other
>>> processors.  It's just as possible that the overhead of the
>>> communications between the two costs too much to justify doing it
>>> that way.
>>>
>>> I would probably suggest that clamdscan/clamd always be used instead
>>> of just clamscan.  From what I've seen using clamscan alone is the
>>> worst possible case performance wise.
>>>
>>> Rich
>>
>> I can't disagree with that but I can say performance is not
>> unreasonable using clamscan. Messages for us take from 2 to 6 seconds
>> to process in batches from 1 to 4 messages. We stop most of our
>> messages long before they ever hit AV scanning. Not using clamdscan or
>> clamavmodule leaves us with one less process to monitor on our MS
>> servers, and changes/updates made by the ClamAV team have never
>> adversely affected us (so far...).
>>
>> We may move up to clamdscan or clamavmodule in the near future when we
>> upgrade the MS servers, but right now I can see no compelling reason
>> to do so. I tend to always favor stability over performance, and I
>> abhor surprises on Monday mornings. Call me a Luddite, but new ain't
>> always better.
>>
>> Also, it's not like we don't process a few connections either, here
>> are a single days stats for one of our servers.
>>
>> Rejected by Greylisting       196,047
>> Blocked for Pipelining         11,072
>> Blocked for RFC                18,528
>> Blocked for RBL                94,857
>> Blocked for Bad Sender          2,746
>> Blocked for No Account         12,000
>> Found Spam Message             18,778
>> Messages Delivered             33,840
>>
>> DAve
>>
>>
> I understand completely.  I'm sure that for many the clamscan approach
> is satisfactory -- clean and simple.  My situation is such that I can't
> use clamscan at all.  We process nearly 2 million messages per day and
> clamscan can't keep up.  If we want to use ClamAV at all  then
> clamavmodule is our only choice.  In a high volume environment small
> performance improvements make huge differences overall.
> 
> ~rich
> 
Maybe Julian can be convinced to add it as an option. The patches are already
out there, and when he gets to feeling better, maybe a quick scan to see if it
will break something, and then off to SVN.
What is one more option to the dozen supported virus scanning solutions.

-- 

MailScanner is like deodorant...
You hope everybody uses it, and
you notice quickly if they don't!!!!



More information about the MailScanner mailing list