Sander Smeenk:
> Quoting Wietse Venema ([email protected]):
>
> > > Since the mailq calls are done asynchronous two calls might come in
> > > within the same second. I had a few 'showq -t unix -u -c' procs
> > > running, killed them, and now it's fast again. Next time i'll try
> > > and see if they give any usefull strace output.
> >
> > If you run mailq commands in parallel, then everything will get very
> > slow with disk seek operations unless you have an SSD drive. It is
> > like running multple "find" commands. Don't do that.
>
> Okay, sure. But this server does not handle thousands of mails in the
> queue. Just a few (~10) were queued when this issue popped up.
> So i wonder why mailq takes so long to finish in the first place.
> Even if i started 50 mailq procs i'd expect them to finish sooner.
Obviously, *your file system* disagrees with your assessment. It
is taking a non-trivial amount of time to report the content of
some files in the queue directory.
> Also, this doesn't explain why smtp accept (eg, telnet localhost 25)
> took well over 20 seconds to present the SMTP banner. System load at
> the time was 0.00 and a restart of the entire Postfix system magically
> makes everything fast again.
That is a different problem, and there is no reason to claim
that they are related.
The smtp daemon will not respond immediately when all ports are
busy. In fact, the smtp daemon will not only log a warning, it will
even make recommendations how to avoid that condition.
> Could you shed some light on the dark corners i might need to
> investigate when this pops up again? It's a sporadic issue,
> unfortunately.
There are no dark corners. You just need to open your eyes, and
read the warnings that Postfix already logs in plain sight.
Wietse
