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
