Hi Stan Subject: Re: performance tuning - relay Date: Mon, Jun 28, 2010 at 01:23:15AM -0500 Quoting Stan Hoeppner (s...@hardwarefreak.com):
: What piqued my curiosity is why the queue on server2 starting growing, and : rather large at that, _after_ you got the Postfix bottleneck straightened out : on server1. I was expecting this and don't have a problem with this limitation. The maildrop rule is rather long and I knew I would get penalized. However delays on local delivery on Server2 has no impact to production so it's ok. : I would have thought this hardware would be able to get the mails into the : mailboxen as quickly as server1 could push them over, without the queue : building up as you demonstrated in a previous message. Email service is : primarily a disk bound application. IIRC, with the DL385G4 you would have the : Smart Array 6i which is an integrated entry level controller. Even so, with : 128MB of read/write cache and 6x10k(15?)rpm drives on a SCSI 320 bus, even in : a slowish RAID5 configuration, you should easily be able to sync to mailboxen : as many messages as server1 could push over either fast or gigabit ethernet. : This server should be able to sync a few hundred emails to disk per second. : Is the 6i just really horrible at RAID5, or is there something in the software : stack slowing things down? Were you peaking the disk subsystem when the queue : was building? : : I'm not familiar at all with maildrop as I've never used it. That said, I : wouldn't think maildrop alone would cause such a bottleneck. Some versions of : Reiser are known for great speed will lots of small files, at least as far as : delete performance. However, most versions of Reiser do not do so well with : large files. Reiser is normally a good performer with maildir, but doesn't do : so well with mbox, especially once the mbox files get large. Maildrop is just procmail for Maildir. I had to use Maildir format as there are hundreds of thousands of email to the always_bcc email on Server2. : Other disk writes? Is maildrop or any other process you're running creating : extra log stamps per email processed? I assume you're storing the OS, logs, : mail, everything on that RAID5 volume. Is this correct? : : As you stated, you're not really concerned with queue growth on server2. I : went through all this simply because I think you're leaving some performance, : maybe quite a bit, on the table WRT server2. I'm guessing it's in the : OS/software stack and not the hardware. You may be able to get this box : screaming with simple changes (reduce logging to only what's necessary), and : maybe one or two more major changes (maildir to mbox or vice versa, switching : from Reiser--defunct now anyway--to XFS). Or a really big change, dumping : Maildrop/Courier for Dovecot/LDA which is quite a bit quicker from everything : I've read. I say read because I've not used Courier but I have used Dovecot, : and still do. Server2 wasn't my concern, Server1 was :) The issue as far as I could see Server1 was unable to feed enough email to Server2, I knew there was a limit somewhere on Server1 that prevented this. : Sorry if I've wasted your time here. I just thought I'd point out a few : things just in case you get the urge to poke around on server2 looking for a : little performance boost. There is no such thing as wasting time here, I am grateful for anyone to reply to my question. Thanks *_^
