Victor.Duchovnimorganstanley.com
Date: Wed Jun 11 2003 - 13:57:16 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Wed, 11 Jun 2003, Leandro Santi wrote:

> > Postfix only forks one service of each type ("cleanup", "smtpd", ...) at a
> > time. The forked daemon initializes itself and reports (to the master
> > daemon) that it is ready for service. Only when the last forked daemon is
> > ready are new daemons spawned.
>
> I'm not sure whether they report "ready for service". I think that single
> threaded daemons like cleanup and smtpd will only send a MASTER_STAT_TAKEN
> message as soon as a new connection is accept()ed (ie, the first message
> is MASTER_STAT_TAKEN aka "server busy").
>

Sorry, yes the daemons are spawned in the "TAKEN" state, and only become
free after servicing their first request, but the consequences are the
same, process creation+initialization is serialized.

> > In the case of the "smtpd" and "cleanup" daemons each daemon processes 100
> > (default value of the max_use configuration parameter) messages and exits.
> > This means that for each hundred messages delivered master needs to spawn
> > 100 cleanup daemons and 100 smtpd daemons.
>
> Thats the worst case behavior (ie when those messages are sent in a very
> short time interval).
>

With a connection timeout 10s per map and say 2 maps, one gets a maximum
MTA throughput of 5msgs/sec. This is too low for the traffic handled by my
machines. Yes, since this is a throughput issue, it is only seen under
high load. People who redundant backend databases would typically be
interested in performance under high load...

> > It may be useful (when supporting multiple MySQL backends) to implement
> > similar delayed connection logic, so that the connection is completed in
> > the lookup code, rather than in the map open code.
>
> Thats how dict_mysql works: the connection is delayed until the first
> lookup is requested.
>

Great, please test to make sure that listing a non-responding IP as the
first server indeed does not limit the system to 100/N*timeout messages
per second where N==max{cleanup,smtpd}(number of MySQL connections per
daemon).

> > of chroot issues with unix domain sockets, so if the connection is not TCP
> > based, it should not be delayed, presumably folks who run multiple
> > backends connect over TCP.
>
> Good catch. I didn't have this in mind. Maybe its better to split the
> timeout option into "connect_timeout" and "query_timeout" and to enforce
> "connect_timeout" for inet connections only (or, better yet, to have split
> inet_connect_timeout and unix_connect_timeout parameters).
>

Don't know, I am unfamiliar with the details of the MySQL code. Just
beware that unix domain sockets need to be visible in the chroot jail.
Perhaps people already set MySQL to listen on /var/spool/postfix/mysql
(or similar) and arrange for a symlink inside the jail to point
var/spool/postfix -> ../..

In any case one needs to be careful not to break existing practice, if
your patch delays connection open, but the original code did not.

--
        Viktor.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]