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
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
.
{^_^}
- 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
You can run DProf manually on SA and see what it says about rule timings.
Or at least you are supposed to be able to; the last time I tried it I
couldn't get it to work.
However, there may be a simpler answer. You didn't mention the amount of
ram you have nor the number of children you are
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.
Check Top. This sounds a lot like you are thrashing. The rulesemporium
rules are fairly carefully written to not be processor hogs, although we
have made
At 04:12 AM 8/15/2005, Paul J. Smith wrote:
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
As soon as you touch swap space you're dead. It's not unusual to see times
for processes increase by 10 or even 100 times. (Although about 10 is most
common.)
{^_^}
- Original Message -
From: Paul J. Smith [EMAIL PROTECTED]
Thanks all.
I did check 'top' and did increase the memory
On Mon, Aug 15, 2005 at 06:51:48AM -0700, jdow wrote:
As soon as you touch swap space you're dead. It's not unusual to see times
for processes increase by 10 or even 100 times. (Although about 10 is most
common.)
Happened to us already twice. Is seems to hit 'just by chance'.
I assume it to
Have you changed --max-con-per-child? Usually a sudden bloat in a single
child is due to:
aRunning a Bayes expire in that child
bRunning an Awl expire
cProcessing a message that is very large
You can stop the first two from being problems by running a manual expire
from a cron job
On Mon, Aug 15, 2005 at 07:27:33AM -0700, Loren Wilton wrote:
You can stop the first two from being problems by running a manual expire
from a cron job every so often and disabling the auto-expire runs. You
should have a limit of 250K or so on the mail size to try to keep the third
from being
-Original Message-
From: Paul J. Smith [mailto:[EMAIL PROTECTED]
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chr. v. Stuckrad writes:
On Mon, Aug 15, 2005 at 07:27:33AM -0700, Loren Wilton wrote:
You can stop the first two from being problems by running a manual expire
from a cron job every so often and disabling the auto-expire runs. You
should
From: Herb Martin [EMAIL PROTECTED]
-Original Message-
From: Paul J. Smith [mailto:[EMAIL PROTECTED]
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
13 matches
Mail list logo
