> -----Original Message-----
> From: Matthew Harrell [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, September 02, 1999 3:07 PM
> To: [EMAIL PROTECTED]; Qmail List
> Subject: Re: Any ideas?
>
>
>
> : 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?
>
The machines are Dual's. Proc load is not an issue though, they never peak.
Too many processors, IMO, just compromises stability. Each queue is bound to
a different network card, which isn't really necessary, but convenient. I
feel that it makes a big difference having multiple qmails on multiple
disks. You are undoubtedly not maximizing your memory and cpu on the
machine. If you have all separate drives on a RAID with good cache, you
probably aren't maximizing your SCSI bus either. It is nice to get every
ounce possible out of your equipment.
> : 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?
>
Hopefully you're using 2.2.x. If this is the case you shouldn't need to,
just make sure your file descriptors are high enough
(/proc/sys/kernel/file-max).
> : 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?
>
What I'm referring to is building the messages on a server separate to the
one you're sending the mail from. Your server should still send to clients
via SMTP (just because I imagine most clients don't support QMTP)...
> : 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.
>
The big-todo patch does not affect the entire queue, it only affects the
todo directory. It hashes out the todo directory which is where messages are
dumped when they come into QMail for the first time, before they are
processed. You shouldn't have any probs with it hashed.
> thanks for all the info.
>
> --
> Matthew Harrell Nondeterminism means never
> Bit Twiddlers, Inc. having to say you
> are wrong.
> [EMAIL PROTECTED]
>
Good luck. Keep an eye on your pipe's bandwidth. :)
