Loading ...
Sorry, an error occurred while loading the content.

Re: lots of "lost connection after" : need help with optimization

Expand Messages
  • Proniewski Patrick
    ... that wouldn t be the first time with Mac OS X Server... ... That s why I came here in the first place. ... That s right. And since I ve raised the max
    Message 1 of 31 , Aug 31, 2007
    • 0 Attachment
      On 31 août 07, at 19:43, Wietse Venema wrote:

      > In fact, this behavior would be a (kernel) bug in the TCP
      > implementation.

      that wouldn't be the first time with Mac OS X Server...


      > Rule number one when solving a problem is to make sure that
      > you are solving the RIGHT problem. This means knowning what
      > has basis in fact, and what is merely an unproven assumption.

      That's why I came here in the first place.


      > Lots of sockets in FIN_WAIT* means that one party has closed the
      > 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.

      That's right. And since I've raised the max number of smtpd to 250
      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?

      regards,

      Patrick PRONIEWSKI
      --
      Administrateur Système - SENTIER - Université Lumière Lyon 2
    • Wietse Venema
      ... Additional note: the smtpd may spend some time with DNS lookup of the smtp client s address - hostname (and name - address) mapping. You can speed this
      Message 31 of 31 , Aug 31, 2007
      • 0 Attachment
        Proniewski Patrick:
        > On 31 ao?t 07, at 20:56, Wietse Venema wrote:
        >
        > >> 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.

        Additional note: the smtpd may spend some time with DNS lookup of
        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
        server.

        Wietse
      Your message has been successfully submitted and would be delivered to recipients shortly.