natan:
> > postscreen tries to hand off each 'good' connection to an smtpd
> > process. Apparently, there are not enough of smtpd processes to
> > take those connections, and some kernel-internal queue is filling up
> > resulting in an EAGAIN kernel error code.
> >
> > Possible causes:
> >
> > 1) The default_process_limit of 1200 is too low. In that case a
> > higher default_process_limit would help.
> Hm I try up 20%
Please don't waste time with minuscule changes. I suggest doubling
the number to see if it makes a difference (don't forget "postfix
reload").
> but:
> for local lmt port:10025 - 5 connection
> for incomming from amavis port: 10027- 132 connections
> smtpd - 60 connections (
> ps -e|grep smtpd - 196 connections
1) You show two smtpd process counts. What we need are the
internet-related smtpd processes counts.
2) Network traffic is not constant. What we need are process counts
at the time that postscreen logs the warnings.
> > 2) Your kernel cannot support the default_process_limit of 1200.
> > In that case a higher default_process_limit would not help. Instead,
> > kernel configuration or more memory (or both) would help.
> 5486 ? Ss 6:05 /usr/lib/postfix/sbin/master
> cat /proc/5486/limits
Those are PER-PROCESS resource limits. I just verified that postscreen
does not run into the "Max open files" limit of 4096 as it tries
to hand off a connection, because that would result in an EMFILE
(Too many open files) kernel error code.
Additionally there are SYSTEM-WIDE limits for how much the KERNEL
can handle. These are worth looking at when you're trying to handle
big traffic on a small (virtual) machine.
Wietse
