As I replied directly, "Can't be done."
The time rule 1022 takes depends on all the other 2752 rules you are
running. Changing any one of them changes memory requirements. And if
it is not DNS then you are running into swap memory and will experience
HEAVY slow downs. Reduce the number of concurrent spamd's running to
reduce the memory footprint. Trying to isolate the time for a single
rule can drive you to the funny farm quickly. This is especially true
when you are shy of required memory to keep SpamAssassin completely
in active memory rather than having it swap pieces in and out.
{^_^}
----- Original Message -----
From: "Paul J. Smith" <[EMAIL PROTECTED]>
To: "jdow" <[EMAIL PROTECTED]>; <users@spamassassin.apache.org>
Sent: 2005 August, 15, Monday 01:45
Subject: RE: Very long scan times - Finding the culprit rule
Hi,
DNS is working fine. We've been running SA for 6 months no problem,
it's only when we added the extra 10 rule sets it got bogged down. I've
just been removing them one by one at the moment and have got the timing
back down to 6 secs or so, but it would be very handy to have the actual
times of each test logged so I can see which are the slow ones.
-----Original Message-----
From: jdow [mailto:[EMAIL PROTECTED]
Sent: 15 August 2005 09:38
To: users@spamassassin.apache.org
Subject: Re: Very long scan times - Finding the culprit rule
Candidate rules right off the bat are DNS based if you are seeing
long delays. You probably have a half dozen or more DNS based rules
setup and DNS is not working.
{^_^}
----- Original Message -----
From: "Paul J. Smith" <[EMAIL PROTECTED]>
Hi,
We are currently seeing scan times of 60-90 seconds on a P4 3Ghz box
after adding some new rules emporium rules to try to increase the
effectiveness of spamassassin.
Is there a way to list the timing for each test rather that the total
scan time so I can see which parts are taking significant time and drop
them?
Thanks.
