Upgrade to clamav 0.90.2 makes scanning extremely slow
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?
>>> 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.
>> 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
> 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.
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