On 16 May 2006 at 16:25, Justin Mason wrote:

> 
> check to ensure your SA-Exim checks are conditional on a message size
> check; at least in 2005, it didn't use the recommended size limits by
> default for some reason, which meant it allowed spamd to balloon out
> of control. Maybe that is still the case. see this thread:
> 
> http://www.exim.org/mail-archives/exim-users/Week-of-Mon-20050221/msg0
> 0218.html

It doesn't scan messages over 250KB.

# How much of the body we feed to spamassassin (in bytes)
# Default is 250KB
SAmaxbody: 256000

# Default is 0: do not scan messages that are too big
# (note that this is parsed as a condition)
SATruncBodyCond: 0

======= from the mail log ==== 
SA: Action: check skipped due to message size (5476972 bytes) and 
SATruncBodyCond expanded to false  


I must admit that things have cooled down a bit since I 1) turned 
SAEximDebug off and 2) reduced the number of spamd children from 10 
to 6. 

I also took the ridiculous step of dedicating an entire 36GB disk to 
swap as the system looked like it was about to fall over. The amount 
of swapping has fallen although not to a level I would like.

Mem:   1289944k total,   914336k used,   375608k free,    31680k buffers
Swap: 35993400k total,   253848k used, 35739552k free,    35624k cached

There is this in the ANNOUNCE notes for SpamAssassin 3.1:

"Apache preforking algorithm adopted; number of spamd child processes 
is now scaled, according to demand.  This provides better VM 
behaviour when not under peak load."  

Which indicates a performance enhancement in 3.1 over 3.0. Perhaps an 
upgrade would help.

Thanx.
Dp.




> Dermot Paikkos writes:
> > On 16 May 2006 at 10:07, Matt Kettler wrote:
> > > Dermot Paikkos wrote:
> > > > Hi 
> > > >
> > > > Spamassassin 3.02 running from SA-Exim (exim 4.5).
> > > >
> > > > OPTIONS="--nouser-config --max-children 6 --helper-home-
> > > > dir=/var/spool/spamassassin/ -s /var/log/spamd.log
> > > > --username=nobody"
> > > >
> > > > I recently went live with the above system and am noticing some
> > > > very heavy memory usage. Each spamd is using near or over 200MB.
> > > That's highly unusual.. Did you download any add-on rulesets? In
> > > particular, did you add sa-blacklist? If so, remove it.
> > > 
> > I agree - I am no expert - but this seems high. 
> > 
> > ========= top output ========
> > PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> > 16099 nobody    18   0  202m 171m  59m R 85.8 13.6   7:30.15 spamd
> > 16098 nobody    12   0  245m 198m  39m S 11.2 15.8   8:00.58 spamd
> > 32020 root      18   0  1664 1664 1296 R  2.2  0.1   0:02.05 top
> >  50 root      12   0     0    0    0 S  0.0  0.0   0:48.54 kjournald
> > 15818 root      12   0  2696 2216 2176 S  0.0  0.2   0:03.55 sshd
> > ==========================
> > 
> > On the matter of more computers; between 06:30 and 15:47 today we
> > have received 2040 mail and delivered 2407. Today has been
> > exceptional as there is a backlog of mail from the server upgrade. I
> > am not sure what sort of bracket that puts us in but I wouldn't say
> > we're a big site in terms of number emails. What's more we don't
> > have the budget or resources to build a server farm for mail and I
> > don't think it's really necessary. I think the problem is either in
> > my configuration or with my version of SA.
> > 
> > Autolearn isn't on. I would have thought that would have given me a
> > performance boost.
> > 
> > The config does have several blacklists by default. I haven't added
> > any. For example:
> > 
> > # the black list. See /usr/share/doc/exim4-config/default_acl for 
> > details.
> >   deny
> >     message = sender envelope address $sender_address is locally 
> > blacklisted here. If you think this is wrong, get in touch with
> > postmaster
> >     !acl = acl_whitelist_local_deny
> >     senders = ${if exists{CONFDIR/local_sender_blacklist}\
> >                    {CONFDIR/local_sender_blacklist}\
> >                    {}}
> > 
> > ditto for hosts. I do have a local_hosts_blacklist which has 1118
> > lines in. Is this what you mean by remove the sa-blacklist?
> > 
> > I had SA 3.0 running on a test system and I noticed this behaviour
> > before. It seemed to go away with V3.1. Problem is there isn't a
> > version of 3.1 in the stable distro of Debian just yet and I don't
> > want to use un-tested stuff on a production system.
> > 
> > Thanx.
> > Dp.
> > 
> > 
> > These are some custom rulesets I have installed.
> >  70_sare_bayes_poison_nxm.cf
> >  70_sare_evilnum0.cf
> >  70_sare_evilnum1.cf
> >  70_sare_evilnum2.cf
> >  70_sare_header0.cf
> >  70_sare_header1.cf
> >  70_sare_header2.cf
> >  70_sare_header3.cf
> >  70_sare_html.cf
> >  70_sare_obfu0.cf
> >  70_sare_obfu1.cf
> >  70_sare_oem.cf
> >  70_sare_random.cf
> >  70_sare_specific.cf
> >  70_sare_unsub.cf
> >  70_sare_uri0.cf
> >  72_sare_redirect_post3.0.0.cf
> >  99_FVGT_Tripwire.cf
> >  99_sare_fraud_post25x.cf
> >  anti_bayes.cf
> >  bogus-virus-warnings.cf


Reply via email to