: Your problem is not QMail, it's disk. We've been configuring an array of
: servers to allow us to send approximately 1000 messages per second from a
: span of 4 servers, each running 4 separate qmail queues on 4 separate disks.
Actually, one of my next thoughts was to try multiple instantiations of qmail
on the same machine. I'm getting in a series of Compaqs with four drives each
on them and I thought this might be a good utilization of all that disk space
if it made sense. I wasn't sure how much of a difference multiple
instantiations might make on the same machine but I was going to give it a
try. You have four queues - do those machines have four processors or less?
: My first recommendation is to turn up the concurrencyremote. The majority of
: the time in *most* SMTP transactions is establishing the connection and then
: closing it at the finish. You can bypass QMail's limit of 255 by making a
: small code modification, but do this carefully--you may need to turn up your
: operating system's max procs.
Agreed. I thought the limit was 120 but I was going to go digging into the
code today to find out where it's listed.
How do I turn up the number of concurrent processes under Linux?
: I'd build a RAID configuration with a large disk cache. Of all the various
: things we've done, the raid cache made the most significant performance
: increase. High speed 10k rpm drives (shameless plug for Seagate's
: Cheetah...) allow for fast queue retrieval and the cache allows for fast
: queue filling. I would put those fsyncs back in. No fsyncs is evil :) But
: I'm sure you already knew that part.
The Compaq's have a RAID controller on them. I'll have to break out the book
and figure out how to work with it. Luckily, it's now supported under the
Linux kernels.
: Now this may or may not be an issue, but generating the messages on the same
: server you send from may slow you down. We are able to fill a queue via
: qmail-smtpd at about 300 messages or so per second to any one qmail but via
: qmail-inject it's only around 400--not that significant of an increase. With
: that in mind, it doesn't seem like its worth wasting processor cycles to
: save that extra time. In fact if you send via qmtp it would probably be even
: closer to 400 per second.
Generate them on one machine and use qmtp to pass them to the client machines?
That's pretty much what I was doing already although I haven't bothered to
time it yet. How have you timed it?
: Also, what's wrong with a 100k+ queue? The majority of your messages are not
: deferalls, they succeed. That tells me that your messages are getting
: through the first time the queue picks them up and processes them. A lot of
: messages should only slow you down if they continually fail. If 50% fail, it
: is only sending half as many messages per second as it could. Fill the queue
: so qmail doesn't have to worry about doing it while you're sending.. I would
: fill it as fast as I can so qmail doesn't have to worry about doing 2 things
: at once. Then again, I'm wrong sometimes too. :)
Well, without the big-todo patch that allows a hashed queue that many messages
is supposed to slow qmail down badly. I personally haven't done time trials
on it but I have noticed a change. Even with the patch I just assumed it must
be detrimental to load it up that badly. I would be glad to hear that isn't
the case, though.
thanks for all the info.
--
Matthew Harrell Nondeterminism means never
Bit Twiddlers, Inc. having to say you are wrong.
[EMAIL PROTECTED]
