On Apr 10, 2017, at 11:25 PM, David Krantz wrote:
Now running mailman 3 I am a bit surprised that the memory footprint is so large. I count to 13 processes
These correspond to the runners, most of which are long running processes that sleep for a while, then wake up and dequeue messages for handling. We model the REST API and LMTP servers as runners as well, but they are technically different since both listen on ports for connections. There's also a master process that controls the runner subprocesses.
This architecture is some of the oldest and most stable bits of Mailman, and while the details have changed, the essential nature of these processes are largely inherited from Mailman 2. Given the technology at the time, it was the best way of doing things. It's probably still the most generic way of doing it, since they don't rely on much more than standard POSIX semantics, so they run on just about any POSIX-compatible system right out of the box.
I can imagine different ways of doing it. For example, systemd socket activation on OSes that support that for the REST and LMTP servers. And maybe use inotify in the master watcher to spawn queue processing runners on demand. These would all be interesting things to explore, although they may not be universally appropriate (i.e. not all *nix systems supported by Mailman run systemd, nor support inotify).