Greg Sims:
> I am tuning the performance of our mail server. We collect
> information in our logs every 10 seconds including qshape, iostat,
> free and mpstat. It seems that the maxproc parameter in master.cf is
> important for us as we can see the size of the queues decrease as we
> increase maxproc -- as expected.
>
> We are currently running with qshape showing 1,000 emails in the
> incoming/active queue maximum -- all less than 5 minutes. Our
> processor load average is less than 1.0 running four cores. We have 4
> GB of memory and 2.8 GB available and no swapping. 80% of the email
> sent is taking advantage of connection reuse for the large ISPs. We
> have four smtp transports with 64 maxproc each.
>
> Should we try to reduce the size of the queue to zero by increasing
> maxproc? Is there some advantage to having moderate size queues for
> connection reuse and the like?
Postfix outbound connection reuse is determined by the initial
xxx_initial_destination_concurrency, and by the competition for
delivery resources by different destinations.
You decrease the competition by increasing the process limit.
For each destination the concurrency slowly rises over time until
it reaches xxx_destination_concurrency_limit, until an error, or
until Postfix is unable to maintain that concurrency level (whether
because of comptetition from other destinations, or because of not
enough email in the queue).
> What is the best way to tell how many processes per smtp transport are
> actually being used at a point in time? I would like to add this to
> our logs every 10 seconds.
netstat or lsof? Only the Postfix queue manager knows what deliveries
are in progress, and it has never evolved a 'live status' API. None
of the Postfix daemons has a status query API, it just isn't part of
the architecture.
And running qshape, mailq, or 'postqueue -p' all the time puts a
lot of load on the queue file system.
Wietse
