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

262293Re: smtpd processes congregating at the pub

Expand Messages
  • Wietse Venema
    Jan 30, 2010
      Stan Hoeppner:
      > Wietse Venema put forth on 1/29/2010 6:15 AM:
      > > Stan Hoeppner:
      > >> Based on purely visual non-scientific observation (top), it seems my smtpd
      > >> processes on my MX hang around much longer in (Debian) 2.5.5 than they did in
      > >> (Debian) 2.3.8. In 2.3.8 Master seemed to build them and tear them down very
      > >
      > > Perhaps Debian changed this:
      > > http://www.postfix.org/postconf.5.html#max_idle
      > >
      > > The Postfix default is 100s.
      > Yes, I confirmed this on my system.
      > > I don't really see why anyone would shorten this - that's a waste
      > > of CPU cycles. In particular, stopping Postfix daemons after 10s

      Allow me to present a tutorial on Postfix and operating system basics.

      Postfix reuses processes for the same reasons that Apache does;
      however, Apache always runs a fixed minimum amount of daemons,
      whereas Postfix will dynamically shrink to zero smtpd processes
      over time.

      Therefore, people who believe that Postfix processes should not be
      running in the absence of client requests, should also terminate
      their Apache processes until a connection arrives. No-one does that.

      If people believe that each smtpd process uses 15MB of RAM, and
      that two smtpd processes use 30MB of RAM, then that would have been
      correct had Postfix been running on MS-DOS.

      First, the physical memory footprint of a process (called resident
      memory size) is smaller than the virtual memory footprint (which
      comprises all addressable memory including the executable, libraries,
      data, heap and stack). With FreeBSD 8.0 I see an smtpd VSZ/RSS of
      6.9MB/4.8MB; with Fedora Core 11, 4.2MB/1.8MB; and with FreeBSD
      4.1 it's 1.8MB/1.4MB. Ten years of system library bloat.

      Second, when multiple processes execute the same executable file
      and libraries, those processes will share a single memory copy of
      the code and constants of that executable file and libraries.
      Therefore, a large portion of their resident memory sizes will
      actually map onto the same physical memory pages. 15+15 != 30.

      Third, some code uses mmap() to allocate memory that is mapped from
      a file. This adds to the virtual memory footprint of each process,
      but of course only the pages that are actually accessed will add
      to the resident memory size. In the case of Postfix, this mechanism
      is used by Berkeley DB to allocate a 16MB shared-memory read buffer.

      There are some other tricks that allow for further savings (such
      as copy-on-write, which allows sharing of a memory page until a
      process attempts to write to it) but in the case of Postfix, those
      savings will be modest.

    • Show all 16 messages in this topic