Shawn Estes <[EMAIL PROTECTED]> wrote:

Dave Sill had some good debugging/pinpointing advice for you in a separate
message.  I'll add a few things here.

> 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.

You're running a significant load -- disk I/O bandwidth and latency are
probably at least part of the problem you're experiencing.  Switching to a
15kRPM disk on a U160 controller would almost certainly help -- it will at
least double available queue disk I/O bandwidth, while halving rotational
latency.  qmail does fsyncs at critical times to ensure reliability, and those
each involve a disk seek; halving the rotational latency will reduce the
access time significantly.

> 1) qmail-qstat is showing that the "not yet preprocessed" messages are
> growing, and very seldom is that number decreasing.

qmail-send is having a hard time keeping up to the rate at which you are
injecting messages.

> 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.

So when no messages are being injected, your system can deliver at reasonable
speed, but as soon as you turn on qmail-smtpd, it can no longer keep up.

> I appreciate any help that anyone can give me. I'm hoping that this is an
> easy problem that I am just overlooking. If anymore information is needed,
> please let me know.

At a few hundred dollars for a 9GB 15kRPM disk, I'd say it's certainly a
simple way to improve your system performance.

> subdirectory split: 23.

This is something else you might want to change.  With 8000 messages in the
queue and a subdir split of 23, you're averaging around 350 files per
directory -- I've not had good luck with FFS-based systems when my directories
have more than about 200 files each.  Perhaps try something higher (remember,
it should be prime).  If you can't just vaporize the current contents of the
queue or take the system down for a few hours, the way to switch over will be
to temporarily run two instances of qmail in parallel.

Charles
-- 
-----------------------------------------------------------------------
Charles Cazabon                            <[EMAIL PROTECTED]>
GPL'ed software available at:  http://www.qcc.sk.ca/~charlesc/software/
Any opinions expressed are just that -- my opinions.
-----------------------------------------------------------------------

Reply via email to