Wietse,
Thank you for your answer.
> Eduardo M . Stelmaszczyk:
> > Hello,
> >
> > I'm having problems with mail accumulating in the incoming queue under
> > heavy load (2500+ SMTPd processes). The queue manager stops for a long
> > time once in a while after trying to communicate with the "trace" client,
> > as shown in a trace from cleanup below:
> >
> > --
> > open("public/qmgr", O_WRONLY|O_NONBLOCK) = 14
> > fstat64(14, {st_mode=S_IFIFO|0622, st_size=0, ...}) = 0
> > lstat64("public/qmgr", {st_mode=S_IFIFO|0622, st_size=0, ...}) = 0
> > fcntl64(14, F_GETFL) = 0x801 (flags O_WRONLY|O_NONBLOCK)
> > fcntl64(14, F_SETFL, O_WRONLY|O_NONBLOCK) = 0
> > poll([{fd=14, events=POLLOUT}], 1, 10000) = 0
> > close(14) = 0
>
> The queue manager has a synchronous trace_flush() client, which is
> used for DSN NOTIFY=SUCCESS notification, and for sender/recipient
> address verification. This trace_flush() client is subject to delays
> in the cleanup server:
>
> - trigger_timeout (default 10s) when the qmgr FIFO is full. The
> minumum value is 1.
It looks like to me that this is the case here (qmgr FIFO full), just as
it was in the "bounce" case, since:
- The files accumulating in the incoming queue have mode 0700 (ready to
be moved to the active queue)
- The timeout you see in the poll call above comes from trigger_timeout
(I've changed it and tested)
- There ARE resources available in the server (memory, CPU and I/O)
This leads be to believe that there's no good reason for the queue
manager not to be moving these messages to the active queue.
>
> - in_flow_delay (default 1s) when new mail gets ahead of deliveries.
> To disable, use "in_flow_delay = 0".
>
> I am not aware of other delays.
>
> If your Postfix is doing address verification on a large scale,
> that may not be a good idea.
Yes, I do some address verification, but that doesn't seem to be a
problem since when I disable DSNs the problem disappears.
As for the in_flow_delay and trigger_timeout parameters: I've tried
changing them before reporting the problem here, but unfortunately they
didn't help much.
>
> If your Postfix is sending lots of DSN NOTIFY=SUCCESS messages for
> SMTP mail, turn off DSN on the SMTP daemon. One example from
> http://www.postfix.org/DSN_README.html shows this:
>
> /etc/postfix/main.cf:
> smtpd_discard_ehlo_keyword_address_maps =
> cidr:/etc/postfix/esmtp_access
>
> /etc/postfix/esmtp_access:
> # Allow DSN requests from local subnet only
> 192.168.0.0/28 silent-discard
> 0.0.0.0/0 silent-discard, dsn
> ::/0 silent-discard, dsn
>
> Another option is
>
> /etc/postfix/main.cf:
> smtpd_discard_ehlo_keywords = silent-discard, dsn
>
> meaning don't send DSN NOTIFY for anyone.
>
> DSN was added long after the synchronous tls_flush() client
> which was not designed for high volume.
>
> Wietse
I would disable DSNs if I could, but unfortunately I'm not allowed to do
that since it's a service the users need.
Regards,
Eduardo
