On Wed, Oct 21, 2009 at 09:34:50AM -0700, Eric Vaughn wrote:
>
> We suspect a few things. It seems to be resolved now. Concurrency
> rates were greatly increased during the last test.
>
> 1) Postfix 2.6 allows for a higher per process limit. The OS "ulimit"
> by default, may not necessarily support this. The postfix processes
> were running out of file descriptors. "ulimit" was increased to 4096.
> 2) selinux was enabled. This was not high on the suspect list, but it
> should be disabled in any high transaction environment.
The systems in question are an extremely unusual Postfix use-case:
- Postfix is only used for (smtpd(8)) TLS termination, proxying
decrypted traffic to a down-stream, non TLS system.
- There are no delivery agents, nothing is ever written to the incoming
queue, ... The only disk (write) activity is from the syslog server.
- The back-end systems do moderately expensive processing, yielding
moderately
high "." latency, and messages arrive at high volumes over a WAN link,
so peak concurrency is high.
- The "tlsmgr" process multiplexes over 1000 smtpd(8) clients that need
to read the TLS session cache and seed their entropy pool, ...
There is no evidence at this time that Postfix 2.6 is "slower", and no
reason to expect this to be the case. Rather, in addition to a new Postfix,
the entire system has new hardware, a new O/S, ... and orignally also SELinux
enabled. Too many variables to make direct comparisons. Also the initial
observations of the new system were not sufficiently well instrumented, and
the impression of "slow" performance could not be corroborated by real
measurements.
With SELinux turned off, and proper measurements conducted, no performance
degradation has been observed. Another set of measurements is still
pending where the volume generating clients are driven to peak (rather
than steady-state) capacity. I expect that these tests will also find
2.6 no slower than 2.5. There is nothing in the 2.6 smtpd(8) to slow
down decryption and smtpd_proxy support.
We may discover that > 1000 smtpd(8) processes is slower than the previous
limit of 1000 smtpd processes, even in the face of latency which causes
the majority to be idle at a given time. Perhaps kernel paging activity,
or other overhead makes it difficult to extract more performance.
In any case. I don't see anything in this use-case that bears on real
Postfix MTA deployments.
When the final measurements are done, if anything interesting is found,
and understood, we'll report what we can.
--
Viktor.
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.
To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:majord...@postfix.org?body=unsubscribe%20postfix-users>
If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
