Re: lots of "lost connection after" : need help with optimization
- On 31 août 07, at 19:43, Wietse Venema wrote:
> In fact, this behavior would be a (kernel) bug in the TCPthat wouldn't be the first time with Mac OS X Server...
> Rule number one when solving a problem is to make sure thatThat's why I came here in the first place.
> you are solving the RIGHT problem. This means knowning what
> has basis in fact, and what is merely an unproven assumption.
> Lots of sockets in FIN_WAIT* means that one party has closed theThat's right. And since I've raised the max number of smtpd to 250
> connection but the other has not.
> In the scenario that you seem to have, remote SMTP clients have
> closed the connection but the Postfix server has not. This is what
> happens when the number of connections exceeds the capacity of the
> smtpd processes: connections queue up in the kernel waiting until
> an smtpd process becomes available, which then sees that the client
> has already disconnected.
and tuned 1 or 2 things in main.cf, the number of sockets in
fin_wait_1 state has decreased.
Let's see if I can put all the pieces together:
- the smtp client connects to my box, but no smtpd is available
- the connection is handled by the kernel, and the kernel waits for a
free smtpd to plug on this connection
- after some time, the smtp client disconnects, and the socket
appears in FIN_WAIT_1 state in netstat
- after some time, a smtpd process is freed and the kernel transfer
the socket to it
(- here, may be it was pure luck, I was able to find a smtpd hooked
on that socket by using lsof)
- the smtpd sends the banner into the socket, only to find out that
nobody is listening on the other side.
- the smtpd closes the socket and is available for another connection.
Am I right?
in that case, how long would an smtpd process be unavailable (busy
dismissing the broken connection)? Is that a matter of instant, or is
it ruled by some postfix timeout parameter?
Administrateur Système - SENTIER - Université Lumière Lyon 2
- Proniewski Patrick:
> On 31 ao?t 07, at 20:56, Wietse Venema wrote:Additional note: the smtpd may spend some time with DNS lookup of
> >> in that case, how long would an smtpd process be unavailable (busy
> >> dismissing the broken connection)?
> > The smtpd does not spend time dismissing connections. That is
> > done in the background, asynchronously, by the TCP/IP stack in
> > the kernel.
> > The smtpd close() request returns immediately, the kernel immediately
> > tells smtpd that there is another connection waiting to be serviced,
> > and smtpd immediately accepts another connection.
> Ok, thanks a lot for the explanation. Now it's pretty clear to me.
the smtp client's address -> hostname (and name -> address) mapping.
You can speed this up with "smtpd_peername_lookup = no" (Postfix
2.3) or by adding an empty in-addr.arpa zone on your local DNS