On Wed, Jun 20, 2001 at 10:11:35PM -0600, Charles Cazabon wrote:
> Off the top of my head, the following suggestions have come up in the past
> when dealing with large qmail installations, in no particular order:
>
> -throw Solaris in the bin. It's networking libraries are bloated and buggy,
> and its filesystem performance sucks rocks.
absolutely. from my experience qmail runs best on bsd systems.
> -ensure the queue is on its own {disk, SCSI disk, 15kRPM SCSI disk, 15kRPM
> SCSI RAID array)
yes, and (for bsd) be careful with softupdates (this is no performance
issue) and mount it noatime.
> -ensure logs are through multilog (not splogger/syslog) to a fast disk
softupdates are fine here, mount noatime, too.
> -deliver locally to Maildirs on a NetApp Filer or similar high-performance
> storage solution
Depends heavily on your usage. disk bandwidth here is not that important as
it is for the queue. if most of your messages are outgoing it isn't very
important at all.
> -use big-todo and big-concurrency patches
No. maex did a nice test regarding big concurrencies. deliveries were
fastest at a remote concurrency about 200 if memory serves me right. this is
not really a qmail issue - in fact most remote servers aren't fast enough.
this causes lots of requeueing and therefore slows down the overall process.
if you don't have lot's of bandwidth available (means: free - if you have a
T3 uplink and it's used at 99% that doesn't count), smaller values may be
more effective.
If the big-todo patch causes better performance depends haevily on the
filesystem. it can even slow down deliveries. I'd avoid that patch as long
as possible. depending on your queue size and the file system using an
appropriate conf-split is far more effective.
> -ensure you've got a dnscache running on the server for maximum DNS
> performance
absolutely ;-))
Greetings
Henning
--
* Henning Brauer, [EMAIL PROTECTED], http://www.bsws.de *
* Roedingsmarkt 14, 20459 Hamburg, Germany *
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)
