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
-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
> > shou
> -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 t
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 be
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 ev
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 t
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 memor
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 c
up from where we are, so I guess a
reasonable machine with just loads of ram is the answer?
-Original Message-
From: Loren Wilton [mailto:[EMAIL PROTECTED]
Sent: 15 August 2005 10:03
To: users@spamassassin.apache.org
Subject: Re: Very long scan times - Finding the culprit rule
> back down
> 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 m
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 runnin
ap pieces in and out.
{^_^}
- Original Message -
From: "Paul J. Smith" <[EMAIL PROTECTED]>
To: "jdow" <[EMAIL PROTECTED]>;
Sent: 2005 August, 15, Monday 01:45
Subject: RE: Very long scan times - Finding the culprit rule
Hi,
DNS is working fine. We've b
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 ba
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 sec
14 matches
Mail list logo