262293Re: smtpd processes congregating at the pub
- Jan 30, 2010Stan Hoeppner:
> Wietse Venema put forth on 1/29/2010 6:15 AM:Allow me to present a tutorial on Postfix and operating system basics.
> > 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
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
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.
- << Previous post in topic Next post in topic >>