t4m6nl902@sneakemail.com (Mike) writes:
> Dave Sill <MaxFreedom@sws5.ornl.gov> wrote in message news:<wx03ceeh2sj.fsf@sws5.ornl.gov>...
>>
>> Before I help you, can you convince me you're not a spammer?
>
> Sure...
OK, thanks. Sorry I had to do that.
> FYI: I have set by conf-split to 503, up from 200. I suspect this may
> help a bit.
You mean conf-spawn? I presume you raised concurrencyremote,
too. Either way, I don't think that'll help much.
> I have also been trying to figure out how to change my
> ext3 filesystem from journaling mode Ordered to writeback. My research
> has indicated that this should improve filesysem response time. I
> haven't been able to get this to work yet... using RedHat 9. So if
> anyone can help out there, I'd appreciate it as well.
The data=writeback mount option should do it, but I don't think you
want to use that on the queue because it can cause problems if the
system crashes. See:
http://lifewithqmail.org/lwq.html#system-requirements
For more information about filesystem requirements for reliable qmail
operation.
Also, have you seen:
http://untroubled.org/benchmarking/
Now, back to your previous message. You wrote:
> What I am seeing is that the rate at which qmail is sending outbound
> email is very low, about 1/10 the rate when all incoming mail has
> ceased. It takes around 2.5 hours for all the emails to get into the
> system right now. So this slower rate goes on for over two hours right
> now. The CPU load is not maxed out and disk I/O looks to be OK as
> well. Any suggestions on what the cause and cure?
Sounds like you're suffering from "silly qmail syndrome": the fact
that qmail-send is single-threaded and handles both the preprocessing
of new messages and the dispatching of queued messages. There's a
patch called qmail-todo that separates these two functions. You might
want to give it a try.
> I know this is not the optimal way of doing this task. Down the road I
> am thinking about writing a front end to format and inject the mail
> into qmail, or maybe into ezmlm... any suggestions about this?
So you're currently you're sending a separate message to each
recipient? Ouch. That's worse than suboptimal, it's pessimal. Using
ezmlm would be a huge performance win. Even injecting the message in
1000- or 100-recipient batches would help tremendously.
> Looking at the qmail.org section on patches for high-volume servers, I
> see the section about servers with queues that get over 23,000. It
> mentions changing conf-split and recomplining. My value for conf-split
> right now is 200... should I change this value to something like 499?
The rule of thumb is that for a non-directory-hashing filesystem, you
don't want much more than 1000 files/directory. With the default
conf-split of 23, that means ~23,000 messages in the queue. You're
queueing 220K messages, so something in the neighborhood of 200 should
be fine. However, to insure even distribution of files in the split
directories, conf-split should be a prime number. The next time you
send a message, take a look at number of files in each of the
queue/mess/* directories. If they're not fairly level, you might want
to fix that. Whether it's a problem or not depends upon how your
filesystem allocates inodes.
The real fix, of course, is to queue one message with 220k recipients
instead of 220K messages with one recipient.
> Thanks for the help gang... I'm clearly a newbie with qmail and I
> really appreciate the help.
As always, I'm glad to help.
--
Dave Sill Oak Ridge National Lab, Workstation Support
Author, The qmail Handbook <http://web.infoave.net/~dsill>
<http://lifewithqmail.org/>: Almost everything you always wanted to know.