Thanks Stan On Mon, Jan 17, 2011 at 11:20 PM, Stan Hoeppner <s...@hardwarefreak.com> wrote: > Jaques Cochet put forth on 1/17/2011 12:18 AM: >> If postfix alone is running on the server, let's say as a mail router >> or backend delivey system, would postfix processes make use of all >> cores? would I be left with cores doing nothing even If I have an >> important number of emails to process? > > I think the answers you're looking: > > 1. *nix kernels all support multiprocessing > 2. they assign available processes/threads to each CPU > 3. Postfix uses a multiple process design > A. one smtpd per concurrent client connection > B. same for content filter processes > C. same for smtp outbound connections > D. etc etc > 4. some Postfix processes are singular > > So, to answer your question, if you have multiple concurrent connections, > Postfix will fork a process for each one. Your *nix kernel will then run each > process on any available CPU (core). The extent to which multiprocessing will > speed up your Postfix server will depend heavily on connection load and how > much > processing you're doing on each connection (AV, AS, content filter, etc). The > more efficient such filters are the less you'll benefit. If they are > inefficient and burn a lot of cycles per process, then having multiple > processors (cores) will be beneficial. > > Now that you understand, to some degree, how Postfix multiprocessing 'works', > take note of what others have already told you. In the _vast_ majority of > situations, Postfix workload wait times and throughput are dominated by the > speed of the disk subsystem and network, not the CPU(s). > > Take for example a typical server from just a few years ago, a 2.6 GHz single > core AMD Opteron with 4 GB RAM, a 100FDX link, and 8*15k RPM SCSI 320 drives > configured as RAID 10 on a hardware RAID card with 256MB BBWC used as the mail > queue and/or mail store. > > The maximum write sink rate of the disk subsystem is 4*300 = 1200 IOS/sec. > Assuming your logs (all logs) are being written to another device, you could > theoretically sustain writing 1,200 emails to spool/store per second. The > size > of each email is mostly irrelevant if we're talking about average size emails > with no attachments--2K-32K. Now note that each email is typically written to > the queue before being written to the mail store. So now you're down to only > 600 emails per second. > > That 100 FDX ethernet link can handle ~6,000 2K emails/sec and ~350 32K > emails/sec, if my math is correct. So for small emails the ethernet outruns > the > disk, and for larger emails the disk slightly outruns the network. Very few > organizations have a sustained mail flow that outruns a 100FDX connection. > > So now the only question is can a single 2.6 GHz Opteron with 4GB RAM handle > 600 > emails/sec without running out of cycles? This will depend largely on how > much > filtering you're doing. With a pre or post queue heavy content filter such as > SpamAssassin doing body analysis along with an anti virus scanner, and some > header checks thrown in, you'd probably be bumping into some CPU limits. With > no content filter or virus scanner, you'd likely have plenty of free CPU > cycles > on this machine at 600 emails/sec. Shared code space of the 600 smtpd > processes > will keep you from running out of memory. 6.4GB/s of memory b/w is overkill > so > that won't be a bottleneck. > > *600* emails/sec = 600*3600*24 = *51,840,000* emails/day. > > Now lets look at something closers to reality, for a larger organization or > small/medium ISP: > > 50 emails/sec = 4,320,000 emails/day. > > With full on filtering that single Opteron server above should be able to > easily > handle 50 emails/sec without breaking a sweat. > > So, to answer your question, thoroughly, with any modern system with a single > core CPU of ~2.5 GHz frequency and a 300 IOPS disk subsystem, you can handle > 50 > emails/sec, or 4.3 million/day, and not come close to running out of CPU or > disk > performance. > > At 50 emails/s you won't _need_ more than one CPU core, but if more than one > is > present, your *nix OS will assign Postfix processes to each/all of them. > You'll > simply have _AMPLE_ excess CPU to handle those spikes of 1200 emails/sec. > But > in that case you're going to need a 16 disk version of the array mentioned > above > and a GbE network link. > > So my question to you is, what is your inbound mail flow rate, and what types > of > mail? Lots of attachments or few/none, and large or small? This will dictate > how much CPU is consumed by your A/V scanner. If most of the emails are spam > and you reject them with a 5xx then you won't need nearly as much disk b/w as > they'll never be queued. > > Lots and lots of variables in this equation. I.e. there is no simple answer > without knowing your mail flow. > > -- > Stan >
-- Jaques ..
