By distributing the work across multiple processes, the process pool provides an effective way to avoid exceeding system-wide process limits on some platforms. Examples of such limits include the Solaris stdio file handle limit, and per-process heap address space limits on other platforms.
If you are using sendmail, the default behavior is to run each milter as a persistent pool of processes to cooperatively service connections from sendmail.
Process pooling is configured using the following settings in pmx.conf (located by default in the /opt/pmx/etc directory):
The PureMessage process pool is useful in at least three ways:
The top-level milter process monitors the pool for unexpected crashes or exits and restarts additional processes as necessary. This means the milter service has much better protection against crashes caused by temporary overload or resource constraints, through the ability to recover automatically when the overloaded or constrained resource conditions are removed.
Pre-forking a pool of persistent processes avoids the overhead of forking processes during each request, on platforms where support for threaded processing is not enabled.
Some systems may have per-process resource limits that are small and cannot be changed. For example, for 32-bit programs using standard input and output, Solaris has a hard limit of 256 file handles that can be allocated by the stdio library within a single process. This in turn limits the number of threads that can be started in a single process, thereby limiting the number of concurrent connections that can be serviced by the milter. Starting a pool of processes, each of which can run a limited number of threads, overcomes such limits.
Every comment submitted here is read (by a human) but we do not reply to specific technical questions. If you need technical support please post a question to our community. Alternatively for licensed products open a support ticket.