On Wed, July 8, 2015 9:30 pm, Jingo Administrator wrote:
I am planning to drop the SecuriteInfo.com signature libraries first,
because these were the last I added and after that the issue began to pop
up.
I am planning to drop the SecuriteInfo.com signature libraries first,
because these
Hello,
SecuriteInfo db Speed...
javascript.ndb: 9079 ms
securiteinfo.hdb: 2969 ms
securiteinfoascii.hdb: 1250 ms
securiteinfohtml.hdb: 2500 ms
spam_marketing.ndb: 1172 ms
SecuriteInfo db memory use:
javascript.ndb loaded
LibClamAV debug: pool memory used: 20.206 MB
On Thu, July 9, 2015 11:11 am, Arnaud Jacques / SecuriteInfo.com wrote:
Thank you for the benchmarks Steve.
We are aware of this problem. With more than 1 million signatures, it
takes too much ram/cpu on lower hardware systems. ATM, we mainly focus on
javascript.ndb and securiteinfohtml.hdb
Jingo Administrator wrote:
Already more than a week ago I posted my first question to the list. I
must admit I'm a bit disappointed that nobody responds. Is it that I
asked a silly question? Or is the issue just to hard to solve and just
nobody wants to burn his fingers on it?
On 07/07/2015
Apologies for cross posting. This question is about Exim and clamd.
Specifically, how can we deal with a clam daemon that’s unresponsive (for five
minutes) while updating rules. The obvious thing would be to wait a bit longer
rather than time out, but I can’t see a control for that. I have some
On 7/7/2015 4:31 PM, Kris Deugau wrote:
Jingo Administrator wrote:
Already more than a week ago I posted my first question to the list. I
must admit I'm a bit disappointed that nobody responds. Is it that I
asked a silly question? Or is the issue just to hard to solve and just
nobody wants to
The system is a VIA PC3500G Motherboard with an onboard VIA Esther
processor 1500MHz. So, indeed, nothing special or heavy, I know,
although it's dedicated:-) . Scanning is not the bottleneck, reloading
the database is. Before this server I had a much slower system with a
VIA C3 processor and 512
It seems to be the elephant in the room, but the root cause of your problem is
you have a resource-constrained system. You don't have enough RAM or CPU to do
what you want. I had the same problem with older Solaris systems running SPARC
processors and no amount of cleverness on my part helped.
On 7/8/2015 11:11 AM, Jingo Administrator wrote:
The system is a VIA PC3500G Motherboard with an onboard VIA Esther
processor 1500MHz. So, indeed, nothing special or heavy, I know,
although it's dedicated:-) . Scanning is not the bottleneck, reloading
the database is. Before this server I had a
On 7/8/15 8:11 AM, Jingo Administrator wrote:
Scanning is not the bottleneck, reloading
the database is.
Because you're wrong about this you cannot correct the real problem. The
bottleneck is the platform. Nothing else.
dp
___
Help us build a
Well, I agree my hardware isn't rather stunning and doesn't help to
(dramatically) reduce the time it takes for clamav to reload the
database. I will draw my conclusion and start to drop the 3rd party
sigs. But no matter how much I can narrow down the problem of the reload
time, and now I come
Jingo Administrator wrote:
Already more than a week ago I posted my first question to the list. I
must admit I'm a bit disappointed that nobody responds. Is it that I
asked a silly question? Or is the issue just to hard to solve and just
nobody wants to burn his fingers on it?
It's like more
12 matches
Mail list logo
