On Thu, Jun 21, 2001 at 03:10:31PM +0200, Karsten W. Rohrbach wrote:
> Henning Brauer([EMAIL PROTECTED])@2001.06.21 12:17:08 +0000:
> > On Wed, Jun 20, 2001 at 10:11:35PM -0600, Charles Cazabon wrote:
> > > -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.
That's not what I meant. with softupdates, qmail _may_ no longer be able to
be absolutely sure that a mail was written on the disc _and_ metadata is
correct. I haven't seen any unexpected softupdates behaviour[1] nore any
problems after forced unclean unmounts (just turning of the machine - for
testing, never do it on a production system...). Therefore I said "be
careful", not "don't use them".
[1] On OpenBSD >= 2.9
> 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
> ;-)
for the queue and /var/log/ it is a performance winning setting.
> > > -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.
re-read this paragraph. i said disk is less important than on queue - simply
due to the fact that there are _much_ more accesses to the queue than to the
maildirs. I did not said disk bandwidth/#transactions/whatever is
unimportant here, it's just not the same performance issue than queue disk
bandwidth. if you use your qmail installation just for huge mailouts (I
don't) this is totally unimportant.
Given the smallest Netapp's cost (> 20000 $) they are simply overkill for
most installations, including big ones. There are installations gaining
performance from using them, though, but this depends - as I said - heavily
on your usage.
> > > -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.
yep, and finding the right value isn't easy. for most installations I
suggest starting with a remote concurrency of 100 or so and looking at your
logs. If you are hitting the concurreny limit often, you have to do some
tests. Bigger values can increase performance, but a (huge!) decrease is also
possible due to heavy requeueing.
> > 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.
absolutely.
> 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)
I totally agree.
One more sidenote: it's vital to monitor your qmail setup. qmail-mrtg (the
version not using qmailanalog from prodigysolutions.com) is very helpful here.
--
* 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)
