Hi there,
In the few days before Fri, 27 Apr 2012, Dennis, Michael, Edwin, Pierre and
Jerry wrote:
On 26 Apr 2012 at 21:18, T?r?k Edwin wrote:
On 04/26/2012 08:37 PM, Michael Orlitzky wrote:
On 04/26/2012 10:32 AM, Dennis Peterson wrote:
On 4/25/12 7:34 AM, Michael Orlitzky wrote:
On 04/25/12 07:55, T?r?k Edwin wrote:
... which DB files are slow to load?
... clamd (and thus the mail server) is effectively down the entire time.
... on memory constrained systems I've cut back on the number of SS signatures.
The signature databases are created once, and loaded thousands of times.
They should just be sorted, so that lookups are instantaneous.
Then it's trivial to update the databases in the background, because you
can quickly determine if a particular signature was added or deleted.
The wall-time-elapsed would be a bit worse, but nobody would care.
Its a bit more complicated than that. ...
It would be easier to just move reload_db to a different thread and
allow scanning with the old database during the DB reload.
... should probably be controlled by a flag in clamd.conf.
... different processes rather than with 2 threads would at least free all
the initial process memory ... would be more tricky between 2 processes...
+1 to the idea. I don't see that there's a problem with the outlined
approaches, and even the odd memory leak might be mitigated. :)
It does seem odd to me that people appear to be running ClamAV on
memeory constrained systems. I'd suggest that those systems might not
be suitable for the task.
The load times have never been a problem to me, but then I don't rely
on ClamAV for dealing with the vast majority of unwanted mail. That's
a luxury I can afford which perhaps most other cannot. But it has to
be worth mentioning that simple things like the GreetPause feature in
Sendmail, dropping connections from dynamic IPs and known spam sources
(particularly by use of dnsbls) and greylisting all consume virtually
no CPU. The vast majority of mail is unwanted; there's absolutely no
need to scan it all because the vast majority of that vast majority is
easily identified as unwanted - without the use of complex tools which
consume a lot of resources. Let ClamAV (and for that matter other CPU
hungry things like SpamAssassin) burn the cycles only when necessary.
Less than one percent of my mail is scanned by ClamAV. This includes
all mail which is sent or accepted. The rest is rejected by very much
simpler, cheaper, smaller and quicker processes.
--
73,
Ged.
_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml
