Wietse Venema put forth on 1/30/2010 9:03 AM:
> Allow me to present a tutorial on Postfix and operating system basics.
Thank you Wietse. I'm always eager to learn. :)
> 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.
Possibly not the best reference example, as I switched to Lighty mainly due to
the Apache behavior you describe, but also due to Apache resource hogging in
general. But I understand your point. It's better to keep one or two processes
resident to service the next inbound requests than to constantly tear down and
then rebuild processes, which causes significant overhead and performance issues
on busy systems.
> 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.
Wouldn't that really depend on the purpose of the server? How about a web admin
daemon running on a small network device? I almost do this with Lighty
currently. I have a single daemon instance that handles all requests, max
processes=1. It's a very lightly loaded server, and a single instance is more
than enough. In fact, given the load, I might possibly look into running Lighty
from inetd, if possible, as I do Samba.
> 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.
Debian 5.0.3, kernel 2.6.31
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29242 postfix 20 0 22408 18m 2268 S 0 4.9 0:00.58 smtpd
29251 postfix 20 0 17264 13m 2208 S 0 3.6 0:00.48 smtpd
> 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.
I was of the understanding that top's SHR column described memory shareable with
other processes. In the real example above from earlier today, it would seem
that my two smtpd processes can only share ~2.2MB of code, data structures, etc.
man top:
t: SHR -- Shared Mem size (kb)
The amount of shared memory used by a task. It simply reflects memory
that could be potentially shared with other
processes.
Am I missing something, or reading my top output incorrectly?
> 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.
Is this 16MB buffer also used for hash and/or cidr tables, and is this
shareable? AFAIK I don't use Berkeley DB tables, only hash (small,few) and cidr
(very large, a handful).
> 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.
I must be screwing something up somewhere then. According to my top output, I'm
only sharing ~2.2MB between smtpd processes, yet I've seen them occupy anywhere
from 11-18MB RES. If the top output is correct, there is a huge amount of
additional sharing that "should" be occurring, no?
Debian runs Postfix in a chroot by default. I know very little about chroot
environments. Could this have something to do with the tiny amount of shared
memory between the smtpds?
Thanks for taking interest in this Wietse. I'm sure I've probably done
something screwy that is easily fixable, and will get that shared memory count
up where it should be.
--
Stan
