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.
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.
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.
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.
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. :)
Try things out and see what gives you the best results. Many factors
influence mail delivery speed. I haven't even gotten into the minor
idiosyncrasies such as network controller (PCI vs ISA actually does make a
difference when you're doing high performance mail delivery... little things
that seem negligible most times often aren't when you go orders of magnitude
higher and volume), or even the type of bandwidth you have to send out on.
For us, 16 messages per second filled a T1 with ~20k messages. Keep in mind
that every little thing goes a long way.
Cris Daniluk
MicroStrategy
> -----Original Message-----
> From: Matthew Harrell [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, September 02, 1999 1:05 PM
> To: Qmail List
> Subject: Any ideas?
>
>
>
> Okay, I'm trying to pull even more out of my qmail box. It's
> a dual P2 450
> with 256 MB of RAM and the following qmail configuration:
>
> qmail with fsync's removed
> concurrencyremote set to 120
> big-todo patch installed
> using cyclog and not syslog
>
> I'm getting what appears to be around 60K messages per hour
> and I'm wondering
> what I can do to get a higher throughput. Any ideas are
> welcome. I'm using
> a Perl script talking directly to qmail-queue to pump the
> messages in (each
> of which is slightly unique) and I know that's not the
> limiter because I have
> to slow the script down to avoid filling the queue up (100K+
> messages). Here's
> some output from qmailanalog:
>
> Completed messages: 196952
> Recipients for completed messages: 196956
> Total delivery attempts for completed messages: 197869
> Average delivery attempts per completed message: 1.00466
> Bytes in completed messages: 1152135331
> Bytes weighted by success: 1140658136
> Average message qtime (s): 12.2331
>
> Total delivery attempts: 202944
> success: 195605
> failure: 2398
> deferral: 4941
> Total ddelay (s): 2338545.236874
> Average ddelay per success (s): 11.955447
> Total xdelay (s): 806842.48747
> Average xdelay per delivery attempt (s): 3.975690
> Time span (days): 0.198014
> Average concurrency: 47.1606
>
> I'll send along vmstat entries if anyone thinks it would
> help. Any ideas?
> I've got multiple boxes here with the same hardware
> configuration just slated
> for this project but if I'm not able to get the rate much
> higher I'm probably
> going to have to consider this whole effort a failure.
>
> thanks
>
> --
> Matthew Harrell Behind every great
> computer sits
> Bit Twiddlers, Inc. a skinny little geek.
> [EMAIL PROTECTED]
>
