Henning Brauer([EMAIL PROTECTED])@2001.06.21 12:17:08 +0000:
> 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.
correct
>
>
> > -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.
when creating large numbers of files and unlinking them afterwards,
softupdates _is_ a performance issue. what softupdates provide is a
synchronous behaviour of metadata which is a good thing, IMVHO. the
bottom line is that you have improved integrity on the filesystem, being
synchronous in it's semantics and nearly the performance of an
ansynchronous mount. please read the design papers to ufs/ffs and
softupdates.
noatime is a good thing when you do not need it. it is not a good idea
to mount noatime on the filesystem where some rdbms stores it's tables
;-)
>
> > -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.
henning, i think you are getting one thing wrong here: when you got a
lot of maildirs, you got a lot of files. disk bandwidth is not the
issue, transactions per second are. netapps do this best in my
experience.
>
> > -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.
sure, you got to scale congruent to your available upstream bandwidth
and the spread of servers you relay mail to.
> 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.
with a good hashing code in your vfs layer and optimizations on the fs
(noatime, softupdates, we already had that) open/net/freebsd do not have
any serious problems with that, if you got enough ram. it is vital to
hold metadata in ram, otherwise performance will suffer. if you do a lot
of stuff with linux systems, you're basically hosed without third party
filesystems like reiser or xfs. ext2 _is_ partly asynchronous by
default, therefor not suitable to be a mail spool or other relevant data
storage. ext2 sucks by default if you switch to synch operation. do not
use linux for mission critical systems (that's my personal opinion,
please direct flames to my personal assistant, d. null)
>
> > -ensure you've got a dnscache running on the server for maximum DNS
> > performance
>
> absolutely ;-))
/k
--
> "There is a God, but He drinks" --Blore
KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie
http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.net/
karsten&rohrbach.de -- alpha&ngenn.net -- alpha&scene.org -- [EMAIL PROTECTED]
GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46
Please do not remove my address from To: and Cc: fields in mailing lists. 10x
PGP signature
