I've had similar problems on our server platform that is much more modest in
both hardware although demand is probably the same.

We generally handle about 300k messages a day inbound that are from outside,
plus there are 20k or so a day internal (we're an ISP, so by internal I mean
messages that don't leave our network).

Our platform is two AMD1700+ processor based mail servers, one acting
primarily as an NFS server, and exports its mail share over NFS.

We had been for a long time experiencing periodic high load issues.  Two
things have fixed this.

The first is simply to reduce the amount of mail handled.  It is probably
desirable to split out your outbound smtp server if you haven't already.
Storage isn't really much of an issue for that, just enough to spool if
something gets backed up.  But, it is read/write intensive on the drive, so
removing it will mean a lot less demand on your disk server.Also, using the
chkuser package to reject messages for unknown users out of hand will also
drastically reduce load on your mail server, as the default unpatched qmail
behavior is to accept such messages, and then send out an error message.
This, again, involves a lot of disk i/o activicty.

The other method that I have done is just to increase the IO on the
fileserver.  We were doing IDE raid1; I have replaced this with a SATA raid 5
system.  That has entirely solved all load issues.  With as many drives as you
have, I would think that the SCSI raid should be able to handle that amount
without a problem.  Use various benchmarking tecnniques to isolate the
issue...do you have bandwidth issues getting to the machine?  Then (if you
haven't already), impliment a seperate physical network using secondary
ethernet interfaces to handle all of NFS traffic.  Upgrade to gigabit.  If it
is disk issues, then make sure that you are tuning the disks as much as
possible.  Isolate all non-essential disk I/O functions to another disk and/or
server (outbound SMTP, accepting of unknown email addresses, and the qmail
queue folder) to reduce unneccesary disk I/O.

Good luck!

-Clint Ricker
Systems and Network Administrator
NorthEast Georgia Internet Access

> I was wondering if anyone is experiencing this same problem, and what 
> different
> approaches are being used to solve it.
> Thanks in advance,
> Duane Wylie

Clint Ricker
Systems and Network Administrator
Northeast Georgia Internet Access (NEGIA)

Reply via email to