Shawn Estes <[EMAIL PROTECTED]> wrote:
>First off, Im using concurrency patch and big-todo patch (from
>qmail.org) with qmail-1.03. I've configured the conf-spawn to 400. We
>are an ISP so we are not doing any kind of mailing lists, all
>messages coming through our system are seperate messages sent by
>different customers. We process about 15,000 different messages an
>hour. We have a server running FreeBSD 4.3, with 256MB RAM, 9GB
>Seagate Barracuda 7200 (this is the disk holding the queue), Quantum
>Fireball is holding the homedirs of the users.
>
>This is kind of broken up into a few different problems.
>
>1) qmail-qstat is showing that the "not yet preprocessed" messages
> are growing, and very seldom is that number decreasing.
>
>
>2) qmail-remote is being spawned way under the current remote
> concurrency limit (175) I have very seldom seen this number reach
> above 30.
Both suggest that qmail-send is having trouble keeping up. qmail-send
is responsible for processing messages placed in the queue and for
scheduling remote deliveries through qmail-rspawn.
The question to answer is why qmail-send isn't keeping up. Perhaps
disk I/O is the bottleneck. Or maybe the CPU is maxed out--though
that's unlikely. What else is the system doing? Is there any idle CPU?
Another possibility is that it's just too busy. You could split the
load somewhat by installing another instance of qmail,
e.g. in /var/qmail2, and let one instance handle locally injected
messages while the other handles SMTP injected messages. Since
qmail-send is single-threaded, it might be not able to keep
qmail-rspawn busy if it keeps seeing new messages that need
processing. Splitting the load like this would mean fewer
interruptions for the qmail-send handling locally injected messages.
>su-2.05# ps -ax | grep qmail-remote | wc -l
> 30
>su-2.05# ps -ax | grep qmail-smtpd | wc -l
> 111
That's a fairly high number of incoming SMTP connections.
>Excerpt from /var/log/qmail/current:
Too small to be useful, and lacking timestamps.
>3) Messages are staying in the queue and are not being delivered the
> way they should be. Note: Messages are going out, just very
> slowly. The logs are showing deliveries local and remote. There
> are no error messages in the log. (A test message sent to a local
> user takes approximately 30-45 minutes, roughly the same amount of
> time for a remote user)
Same problem as 1 and 2.
>Here's what I've done so far:
>
>1) Checked the Trigger file to make sure it has the correct permissions:
Good.
>2) Checked ulimit and kern max files.
OK.
>3) Ran the qmail-send run file by itself and the messages in the
> queue went through very quickly. (5000 messages in about 15
> minutes or so) A lot better then they are with everything
> running.
Confirms my "qmail-send is being interrupted" hypothesis, I think.
>4) Verified my run scripts with LWQ. The run scripts have softlimits
> that are increased from LWQ, could this be my problem?
No, but I wonder why you want such high limits. They're for your own
protection.
-Dave
