Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Delay splitted in logfile

171 views
Skip to first unread message

Xesc Arbona

unread,
Jul 25, 2007, 5:06:43 AM7/25/07
to
Hi everybody,

I am using Postfix as MTA and procmail to deliver local messages. My problem is that delivery is taking very long (5 minutes) when sending a message to all users. To solve this problem, I am looking at Postfix logfile "mail.log". However, I do not fully understand its syntax. Especially how "delay" is divided.

For example, in the following entry:

"Jun 28 15:06:21 foo postfix/pipe[9744]: 7B8A35B864: to=<mi...@foo.bar>, orig_to=<d-eve...@foo.bar>, relay=zarafa, delay=157, delays=13/128/0/16, dsn=2.0.0, status=sent (delivered via zarafa service)"

I see that delay=157 is splitted in 4 values (13, 128, 0 and 16), but I don't know which process/step is causing which delay. Someone knows?

Thank you very much for your attention.

Regards,

--
Xesc Arbona


Ralf Hildebrandt

unread,
Jul 25, 2007, 5:17:40 AM7/25/07
to
* Xesc Arbona <X.Ar...@topdesk.com>:

> "Jun 28 15:06:21 foo postfix/pipe[9744]: 7B8A35B864:
> to=<mi...@foo.bar>, orig_to=<d-eve...@foo.bar>, relay=zarafa,
> delay=157, delays=13/128/0/16, dsn=2.0.0, status=sent (delivered via
> zarafa service)"

>
> I see that delay=157 is splitted in 4 values (13, 128, 0 and 16), but I don't know which process/step is causing which delay. Someone knows?

20051102

Completion of support for time stamps from different stages of message
delivery. The information is now logged as "delays=a/b/c/d" where
a=time before queue manager, including message transmission; b=time in
queue manager; c=connection setup including DNS, HELO and TLS;
d=message transmission time.

--
Ralf Hildebrandt (Ralf.Hil...@charite.de) pl...@charite.de
Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155
http://www.arschkrebs.de
UNIX was not designed to stop you from doing stupid things, because
that would also stop you from doing clever things. -- Doug Gwyn

Victor Duchovni

unread,
Jul 30, 2007, 4:42:13 PM7/30/07
to
On Wed, Jul 25, 2007 at 11:17:40AM +0200, Ralf Hildebrandt wrote:

> * Xesc Arbona <X.Ar...@topdesk.com>:
>
> > "Jun 28 15:06:21 foo postfix/pipe[9744]: 7B8A35B864:
> > to=<mi...@foo.bar>, orig_to=<d-eve...@foo.bar>, relay=zarafa,
> > delay=157, delays=13/128/0/16, dsn=2.0.0, status=sent (delivered via
> > zarafa service)"
>
> >
> > I see that delay=157 is splitted in 4 values (13, 128, 0 and 16), but I don't know which process/step is causing which delay. Someone knows?
>
> 20051102
>
> Completion of support for time stamps from different stages of message
> delivery. The information is now logged as "delays=a/b/c/d" where
> a=time before queue manager, including message transmission; b=time in
> queue manager; c=connection setup including DNS, HELO and TLS;
> d=message transmission time.

In this case, the largest delay is "b", which is time spent in the
active queue waiting for a delivery agent to become available (subject
to process and destination concurrency limits).

If the queue is not overloaded with backscatter bounces (recipient
validation is configured and working), the high delivery latency of 16
seconds could if typical means that at most 20 deliveries take place every
20 seconds, or 1.25 deliveries a second. If the arrival rate is higher,
this destination may need more concurrency, better connection caching,
or other tuning.

--
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:majo...@postfix.org?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

0 new messages