Demi Marie Obenour:
> On 2/7/22 10:00, Wietse Venema wrote:
> > V?ctor Rubiella Monfort:
> >> Hello,
> >>
> >> I'm was reading http://www.postfix.org/TUNING_README.html about increase
> >> number of process configurations related.
> >>
> >> We can increase smtp easly to 1000 connections for example to allow
> >> multiple incoming connections. But what about pickup and qmsg processes?
> >> by default is configuret to 1 process.
> >
> > Not only by default; these programs will actually abort when you
> > change the limit. Likewise, some services such as cleanup require
> > no hard limit.
> >
> > However, increasing the number of processes only improves performce
> > up to the point that the OS kernel can no longer provide resources
> > to all those running processes.
>
> To what extend is Postfix?s process-per-connection architecture a
> limitation here?
The read-only bits (code, constants) are shared; the writable bits
(state) and open files/connections would not be shared even if a
service were implemented with a single process.
So I think that one process per connection does not affect scaling
that much, considering that these programs maintain a non-trivial
amount of state. It may cost a bit more, but it does simplifiy the
implementation. more on that later.
Note that postscreen is a single-process service. This is feasible
because the amount of state per connection can be very small compared
to what smtpd does, and that is possible because postscreen never
receives email.
However, one process per service cannot do the following:
- Resilience: a process cannot terminate with a fatal error without
taking an entire sevice down. This Postfix property alone
simplifies error recovery immensely.
- Rejuvenate: a process cannot terminate after 100 clients, to
reduce the impact of file/memory leaks, in Postfix or in a library.
Postfix has grown its code base by 5x without becoming a mess. Every
major feature is implemented with a new process. This approach
enforces very narrow interfaces, and that is what has kept Postfix
robust and secure.
Wietse
