[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 3.3 panic



Quoting Ted Unangst (tedu_(_at_)_zeitbombe_(_dot_)_org):
> On Fri, 18 Jul 2003, Craig Metz wrote:
> >   The killer process - I think - is multiple instances of SpamAssassin's
> > sa-learn, running in Perl (which is what there was lots of). It's a bit of a
> > pig, and multiple copies of it I can definitely see sucking up VM and CPU
> > cycles. The box was running at a system peak load average in the 30s, which I
> > believe is a very bad place to be.
> 
> my personal belief is that spam filtering is a user problem.  let the
> client boxes run spamassassin, instead of an overloaded mail server.

That's a fine old notion that is rapidly getting outdated.

I'm at a client where their problem is that EASILY 60% of the mail
is spam.  With 14,000 people, that means storage costs, lost
productivity and other real measurable costs.

It's not a user problem when you need more hardware to handle it
when you can block it at your network border.

> > Still, that shouldn't result in a panic. If needed, I can probably get it back
> > reproducing the problem by downgrading it to 64MB.
> 
> insufficient memory is not a supported configuration. :)

I have a 64MB box (on my own)..  It's runs at 150MHz.  It's not a
true production box.  If you want to teach spam assassin, don't do
it live, do it in bulk later.  That way, it's not driven by the
mail load coming it.  You can spool it and serialize it (one message
at a time, not "as many connections as you have at this moment" at
a time).

Also STARTING perl is expensive.  If you can daemonize it, or run
it once and pass it lots of mail, you can reduce the CPU and RAM
costs.

But looking at the paper and seeing my favored x86 MoBo with a 2GHZ
CPU going for $75 and good 512MB RAM going for the same (crucial
DDR_(_at_)_$75), I think excuses for 64MB are thin.