You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Justin Mason <jm...@jmason.org> on 2005/07/12 18:53:44 UTC
Re: Performance: files or SQL?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Parker writes:
> Cami wrote:
>
> > Well.. As for setup, we're using amavisd-new which provides more
> > functionality than spamc/spamd (thus producing more sql queries).
> > As for average scantime per msg, no idea since i dont log that.
> > Hardware wise: Dell PowerEdge 2650, Dual 3.06GHz, 6gigs of ram,
> > 5x32K RPM disks in Raid 10/1+0..
>
> Ahhh....so the more correct statement would be amavisd-new with SQL does
> not scale. Since I assume you are using a global sitewide database with
> amavis this doesn't surprise me. There would be a lot of lock
> contention with that many children attempting to hit a single row in the
> database constantly. A better setup would be individual bayes dbs and
> InnoDB tables (which support row level locking). That would certainly
> scale much better.
Is there any diff between Amavisd and spamd's use of SQL for bayes?
I wouldn't have thought so...
- --j.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Exmh CVS
iD8DBQFC0/WYMJF5cimLx9ARAqs0AJ0bOPkDbcX9T6xtrJkAeGJcwRtPOgCfW7m4
0X2fxfMtNfFkHkBOTAB5OY0=
=QNgY
-----END PGP SIGNATURE-----
Re: Performance: files or SQL?
Posted by Michael Parker <pa...@pobox.com>.
Justin Mason wrote:
> Is there any diff between Amavisd and spamd's use of SQL for bayes?
> I wouldn't have thought so...
No, just the fact that it doesn't generally support (someone feel free
to correct me if I'm wrong) individualized configs (ie everything runs
as a single user). Anyone who attempts a sitewide database with that
many children hitting the db at once will most likely encounter the same
sort of difficulties. However, 4000 queries/sec is not very high (I can
easily push that via 2 spamd children), so I'm actually guessing there
is a broader issue here. Maybe amavisd is doing some additional, poorly
optimized, queries that is causing the database slowness.
Michael