I have three front-end PostFix servers acting as mail relay's for all...
Unfortunately, the physical number of hard drives and their RAID configuration is suboptimal, and changing it isn't an option at this point.
Let me guess, RAID5 for /var?
If you have three front end servers, then change is always an option. Take one of the machines out of service, and fix its RAID configuration.
You may also see a *huge* benefit from turning off atime on paritions with many small files. Mount those filesystems with the "noatime" option.
If the partitions are fairly small, you'll also see a tremendous performance benefit from using ext2 instead of ext3.
If you're using a 500MB - 1GB partition for /var (and you should be), then a RAID0 configuration with and ext2 filesystem mounted with the noatime option will give you your absolute best performance for your postfix servers. Since it's a cluster, any single member can be down for the very short amount of time it takes to fsck a partition. Data redundancy there doesn't make much sense.
/home, if that's where you deliver mail, should be RAID5 with an ext3 filesystem mounted with noatime.
Fortunately, the machine has plenty of memory...
That can actually be a drawback. I have four servers in a cluster. Three of them have 512MB of RAM, one has 1GB of RAM. The one with more memory consistantly has a higher load than the others, as much as 10x. I'm nearly convinced that there's something wrong with the memory manager in the Linux kernels running on those machine's. They're not entirely up to date, and it remains to be seen what happens when I actually get to reboot them to new kernels, but it's still something to bear in mind.
...which leads me to what I was considering. What about mounting the "/var/spool/postfix/incoming" queue and "/var/spool/postfix/active" queue as tmpfs with a max filesystem size of about 500MB a piece.
You may incur more overhead than you've got now, especially if doing so makes the machine start swapping. Fixing your actual filesystems is probably a better idea.
performance. The only downside of this setup I can think of is that in the very unlikely event of a server crash, all of the mail that was stored in the PostFix "incoming" and "active" queues would be lost. Poof. This, however, is an acceptable risk according to management. Thoughts?
I think you have better options.
-- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
