I had these issues before with 3 similar servers in an ISP setup where I had
to continually 'baby-sit' spamd (maybe was a bad setup, didnt do it myself.)
I changed everything to use exim+amavisd setup where I accept mail first
before scanning (exceptions to rbl-listed IPs) and the servers now barely use
more than 10% CPU and always less than 5% I/O wait.
From my experience, scanning at SMTP-time thus has a load on CPU, other people
may differ on the same.
rgds,
Joseph
On Tuesday 19 September 2006 15:56, Graeme Fowler wrote:
> On 19/09/2006 13:44, Mark Adams wrote:
> > I'm talking about the wait time on the disks (iowait) which as defined
> > by iostat manpage
> >
> > %iowait
> > "Show the percentage of time that the CPU or CPUs were idle during which
> > the system had an outstanding disk I/O request."
> >
> > it seems the disks cannot keep up with spamassassin?
> >
> > It is definatly something that I am worrying about as it is causing lag
> > to the SMB service on the same server.
>
> Ah.
>
> In that case, if you've got enough (your definition, not mine!) RAM then
> you could put the SpamAssassin working/Bayes directories onto a RAM
> disk. In fact, while you're at it, put your Exim spool databases onto a
> RAM disk too. You'll marvel (hopefully) at the boost you get in
> performance.
>
> Implementation is left as an exercise for the reader, particularly with
> respects volatility of data and (where necessary) keeping hold of it
> across service restarts and/or system reboots.
>
> Graeme
--
I blog at
http://okechukwu.blogspot.com
Give a man a computer program and you give him a headache,
but teach him to program computers and you give him the power
to create headaches for others for the rest of his life...
-- R. B. Forest