You are correct. Postfix (and MTAs in general) are extremely disk IO intensive. If you're looking into improving performance of the system, I recomend you look into a faster disk subsystem. A lot of work can be done tweaking Postfix for optimal performance too (running a second instance for defered emails, tuning the # of processes and SMTP timeouts, moving spools onto their own disks (or at least separate partitions), if you're willing to risk loosing data in the event of a power outage you can also try using a ramdisk for spool, etc...)
You may be able to squeeze a little more performance out of your existing system by generating (and delivery to postfix) mails in parallel. I was running on a e450 for a while with 4 CPUs and postfix and I found that my optimal generation rate was produced by having 8 simultaneoue mail generation/injection processes. Your performance may vary, but its worth looking into. If you try this, be careful not to flood postfix's mailqueues. If they grow too large performance will suffer. | [reply] |
Yes, the generating in parallel was something we discovered as well. Although the max injection rate (SMTP submits) we could get out of a process was 250,000 per hour, we discovered that doing 2 at a time didn't slow down this rate much. We were thinking of running 4 at a time on each server. But I'll trust and suggest your number 8 - that makes sense. If I can linux to submit at 250,000 by putting it on EMC array (which is like ram disk), we'll be in business with multiple processes.
On a side note, the 250,000 was up from 125,000 when I made the following code change on Net::Cmd ->
line 476__ $main::ignore_response ? 1 : ($cmd->response == CMD_OK);
I noticed alot of delay in waiting for the response when a mail was finished submitting to postfix. I set ignore_response as a global in the sending program.
Thanks for your help and confirmation of the multiple-processes strategy.
--Jim
| [reply]
[d/l] |
