Matthias Jambor wrote:
dear list,
we experience problems with one of our qmail-servers since a few days.
It is a normal qmail-installation with the spamcontrol-patch. It delivers
mail to the local vpopmail-server or to external mailserver per smtproute.
Sometimes qmail-send nearly stops delivery. The queue grows until a few
thousands of mails are waiting to be done.
few thousand preprocessed?
At first we configured an default smtproute to an external relay-server.
Then we installed bind (i know, tinydns would be better) for faster name
resolution.
you mean dnscache
Both did not helped.
Then we reduced concurrencyincoming from 200 to 10-25. After that qmail-send
deliverd the mails so that the queue decreased to a normal value.
Starting or stopping qmail gave no improvement. Neither did force delivery
(tcpok, kill -ALRM qmail-send).
We have to increase the concurrencyincoming back to something about 100.
Looks like an i/o efficiency issue.
Local system:
Quad Opteron Processor 265
2G Ram (always enough free mem left)
Adaptec AAC-RAID (Rocket)
More information on disk subsystem please.
Kernel version: 2.6.18.3 #1 SMP
OS: debian 3.1 (qmailer was compiled from the sources, no .deb-installation)
Average Deliveries last 24h: 13.8 kmsg
Average Deliveries last month: 7855.0 msg
Just ask if I have have to give you more information.
Every help is welcome.
The picture is made from qmailmrtg7 out of the multilog-logfiles.
Just the max concurrency is useless...you need to compare deliveries
against concurrency and also injection rate.
It appears to me that this is a 'seasonal' thing and not a constant
thing. If you really want to make sure queues never build...please tell
us that filesystem the queue is on and the disk subsystem and consider
using the ext-todo patch or big-ext-todo patch (who one depends on your
filesystem although on Linux all should have directory index support by
default) which should make sure qmail-send is busy handling deliveries
and not processing the queue.
|