On Tue, Aug 03, 1999 at 01:59:43PM -0400, Cris Daniluk wrote:
> I have to throw in one more question, albeit somewhat off topic, it has
> definite relevance. We're going to put in a raid controller with a hell of a
> cache in it (64 mb probably). My question then is, what type of disk
> configuration would you propose we need? Space needs are virtually
> nonexistant, the machines sole purpose will be mail. Probably 100 mb for the
> system itself and then the rest will be for the queue. I'd figure a raid
> controller with 64mb cache and a 4.5 gb Cheetah would do the job. Do you
> feel that striping and multiple drives would be valuable?

Basically, your goal is to provide the fastest seek times and small block
write performance possible for your queue'ing process.  Two observations:

1) Configuring a large write-back cache in front of your queue disk is a
   good way to handle qmail's multiple directory writes and sync calls.

2) No FIFO cache will help the qmail's preprocessing.  That can only be
   done by 1) RN's big-todo patch, and 2) increasing the seek performance 
   of the disk array. 
   -THE- solution for (2) is RAID 1+0 or RAID 10, creating mirrored
   pairs of disk drives, then creating a stripe across the mirrored 
   pairs.  This is the highest performance configuration you can make
   (aside from striping across multiple RAID 10's), and not all controllers 
   can actually do it.

What I would do:

1) Use multiple instances of qmail on one of your quad-xenon boxes.
   I'd start with four: /var/qmail1 , /var/qmail2, etc.

2) Use Russ Nelson's big-todo patch

3) Go with your cached raid controller idea with one disk, but make 
   sure you choose one which can do RAID 10 if you need it to.

4) Force your message generation process to Round-Robin balance it's
   message queue'ing to each of the qmail instances.


I question whether you've correctly identified your bottlekneck...
To be specific, how quickly can you generate 1M messages?  What
is your method of queue'ing them?

I'm sure you'll have people suggest that you call qmail-remote directly
and only queue if that fails.  The question then becomes, how robustly
can you recover from the disasters the qmail queue is designed to be
proof against...
 
-- 
John White     johnjohn
             at
               triceratops.com
PGP Public Key: http://www.triceratops.com/john/public-key.pgp

Reply via email to