--jRHKVT23PllUwdXP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I've noticed some odd behavior with spamc/spamd lately. For reference, my s=
etup
is:
1) fetchmail goes and gets my mail
2) qmail delivers it
3) my .qmail spits it 'ifspamh' which passes it through spamc then delivers=
 it
   to the normal target if not spam, to a spambox if spam.

Now, spamd logs to syslog, and mentions the number of seconds it took to sc=
an
the mail. It is almost always between 1 and 4 seconds. Lately (here is where
things get weird) it's always > 30 seconds. 30.1, 31 sometimes, etc. BUT - =
this
seems linked to me setting BUFCACHE or BUFPAGES in my kernel conf. I've done
some limited testing, and a kernel without the BUFCACHE or BUFPAGES options
behaves as expected - spamd takes 1-4 seconds to scan each mail, depending =
on
the size of the mail. If I up BUFCACHE or BUFPAGES, it takes >=3D 30 second=
s.

It's hard for me to see how the two could possibly be related, but has anyb=
ody
else seen spamd take abnormally long to process mail lately?

I'm going to reboot to a non-BUFCACHE-altered kernel (my standard custom ke=
rnel,
without the BUFPAGES option) and see if it still happens. I'm pretty sure t=
he
two are somehow intertwined - I just can't see how or why.

Any input is appreciated.
-Sean


--=20
/~\ The ASCII
\ / Ribbon Campaign                   Sean Davis
 X  Against HTML                       aka dive
/ \ Email!

--jRHKVT23PllUwdXP
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (NetBSD)

iD4DBQE+IcjHcMEZWGhfx9kRAoHWAJYh2TxrJ0+RiOVufOc7U9vZ2vlUAJ9hiE+y
FtRkhb4eaxmipaS/pxIouA==
=Y0zm
-----END PGP SIGNATURE-----

--jRHKVT23PllUwdXP--