On Mon, 7 Jan 2008 08:59:10 -0800, Mark Sapiro wrote:
I have regular delays in message processing. Say, my server (Linux/Postfix) receives a letter at 17:36 and quickly delivers it to the mailman queue (?). Then message is hold for about 25 minutes and is processed again at 18:01.
It is strange to me, why mailman keeps the message so long? How can I investigate such situation?
Maybe, other messages in queue could be the reason?
$ ls -1 /var/lib/mailman/qfiles/in/|wc -l 0 $ ls -1 /var/lib/mailman/qfiles/out/|wc -l 120 $ ls -1 /var/lib/mailman/qfiles/retry/|wc -l 121
Why is the out queue backlogged with 120 messages?
I guess, that is because "retry" messages come back to "out" queue from time to time. In sum "out" and "retry" always give 200-250 letters.
Why are there 121 messages being retried. What is in Mailman's smtp-failure log?
It is full of errors:
Jan 08 01:55:00 2008 (13316) All recipients refused: {'mak@rsmu.ru': (450, '4.1.2 <mak@rsmu.ru>: Recipient address rejected: Domain not found')}, msgid: <20080107110706.GC32553@nevod.ru> Jan 08 01:55:00 2008 (13316) delivery to mak@rsmu.ru failed with code 450: 4.1.2 <mak@rsmu.ru>: Recipient address rejected: Domain not found
with several different emails and different message-ids. About 42000 lines per day.
What does Mailman's smtp log look like? Does it show evidence of 'continuous processing'?
Well, there are messages like this:
Jan 08 01:55:11 2008 (12250) <47815B62.3090806@gmail.com> smtp to sisyphus for 1 recips, completed in 30.005 seconds
About 21000 posts per day, every took 30 seconds "for 1 recips". Should they address more recipients or take less time?
There are 8 Incoming, 8 Outgoing, 4 Retry and 4 Bounce qrunners on the server.
Why so many runners? Do you really need that much parallelism?
I thought they would process queue faster.
The issue appears to be a backlogged 'out' queue. In order to say more, we need to know what's causing all the retries (smtp-failure log) and whether there are outgoing messages taking inordinately long to process (smtp log).
-- Grigory Batalov, ALT Linux Team