Re: paternalism silent concurrency
On Wed, Jun 20, 2001 at 11:33:46PM -0400, Bob C. Ruddy wrote: The running qmail book is great but It isn't. really. at least half the book is not about qmail, the rest isn't better than life with qmail. -- * 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)
Re: paternalism silent concurrency
On Thu, Jun 21, 2001 at 12:17:08PM +0200, Henning Brauer wrote: 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: one additional sidenote: make sure you have ulimit -n 8192 (or so) in your run file for qmail-send. Otherwise pipes between qmail-send/qmail-[lr]spawn/qmail-remote/qmail-local may break and mails can be delivered multiple times. -- * 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)
Re: paternalism silent concurrency
Henning Brauer([EMAIL PROTECTED])@2001.06.21 12:17:08 +:
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/
karstenrohrbach.de -- alphangenn.net -- alphascene.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
Re: paternalism silent concurrency
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. I'm just curious...do you have anything against the qmail-mrtg that uses qmailanalog? ;) Cheers Lars Hansson Technical Cons...whatever
Re: paternalism silent concurrency
On Thu, Jun 21, 2001 at 09:55:12PM +0800, Lars Hansson wrote: 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. I'm just curious...do you have anything against the qmail-mrtg that uses qmailanalog? ;) a) qmail-mrtg-mess doesn't work with multilog b) the other one reports much more and is ways faster -- * 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)
Re: paternalism silent concurrency
We just recompiled qmail with conf-split changed to 512 from the default of 23. Wow we saw a huge increase in the throughput. Thanks. Bob
Re: paternalism silent concurrency
* Bob C. Ruddy [EMAIL PROTECTED] [010621 12:03]: We just recompiled qmail with conf-split changed to 512 from the default of 23. Wow we saw a huge increase in the throughput. Thanks. [http://marc.theaimsgroup.com/?l=qmailm=98228134417057w=2] /pg -- Peter Green : Architekton Internet Services, LLC : [EMAIL PROTECTED] --- What about WRITING it first and rationalizing it afterwards? :-) --- Larry Wall in [EMAIL PROTECTED]
Re: paternalism silent concurrency
Bob C. Ruddy [EMAIL PROTECTED] wrote: We just recompiled qmail with conf-split changed to 512 from the default of 23. Wow we saw a huge increase in the throughput. Thanks. conf-split should be a prime number. Change it to 509 or 521 and you'll probably see another incremental improvement. Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
Re: paternalism silent concurrency
On Thu, Jun 21, 2001 at 12:03:30PM -0400, Bob C. Ruddy wrote: We just recompiled qmail with conf-split changed to 512 from the default of 23. Wow we saw a huge increase in the throughput. Thanks. since when 512 is a prime? -- * 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)
Re: paternalism silent concurrency
Bob C. Ruddy([EMAIL PROTECTED])@2001.06.21 12:03:30 +: We just recompiled qmail with conf-split changed to 512 from the default of 23. Wow we saw a huge increase in the throughput. Thanks. ouch /k -- I think pop music has done more for oral intercourse than anything else that has ever happened, and vice versa. --Frank Zappa KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.net/ karstenrohrbach.de -- alphangenn.net -- alphascene.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
Re: paternalism silent concurrency
Henning Brauer([EMAIL PROTECTED])@2001.06.21 18:13:33 +: On Thu, Jun 21, 2001 at 12:03:30PM -0400, Bob C. Ruddy wrote: We just recompiled qmail with conf-split changed to 512 from the default of 23. Wow we saw a huge increase in the throughput. Thanks. since when 512 is a prime? perhaps the system's c-compiler allows one to cast an arbitrary number a prime ;-) one could patch auto-int: puts(int ); puts(name); puts( = ); puts((prime) ); puts(strnum); puts(;\n); hehe i must be drunk or whatever *grin* /k -- Hackers know all the right MOVs. KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.net/ karstenrohrbach.de -- alphangenn.net -- alphascene.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
paternalism silent concurrency
Below is the top of the output from qmail-showctl. My questions are what is paternalism and silent concurrency? We are running a test now that is just testing the receiving of large numbers of email via smtp and storing it local. What I am seeing is the email coming it and sitting in the Q. This Q keeps gettnig larger and larger. It seems as though there is room on the box as far as IO is concerned. So I'd like to up the local concurrency limit. bob qmail home directory: /var/qmail. user-ext delimiter: -. paternalism (in decimal): 2. silent concurrency limit: 500. subdirectory split: 23. user ids: 7790, 7791, 7792, 0, 7793, 7794, 7795, 7796. group ids: 2108, 2107. badmailfrom: (Default.) Any MAIL FROM is allowed. bouncefrom: (Default.) Bounce user name is MAILER-DAEMON. bouncehost: (Default.) Bounce host name is mailcluster.somehwere.net. concurrencylocal: Local concurrency is 75. concurrencyremote: (Default.) Remote concurrency is 20.
Re: paternalism silent concurrency
Bob C. Ruddy [EMAIL PROTECTED] wrote: Below is the top of the output from qmail-showctl. My questions are what is paternalism and silent concurrency? paternalism is the bits which are not allowed on home directories before qmail will deliver to them. The default, 2, simply means that home directories must not be world writable. The silent concurrency limit is determined by your system headers -- as I understand it, it's a limit of how many fds can be used in a select() set, and therefore it limits how many children qmail-lspawn and qmail-rspawn can have at any given time. What it means is that if you try to set concurrencylocal or concurrencyremote higher than this, it will silently be limited to this limit. We are running a test now that is just testing the receiving of large numbers of email via smtp and storing it local. What I am seeing is the email coming it and sitting in the Q. This Q keeps gettnig larger and larger. It seems as though there is room on the box as far as IO is concerned. So I'd like to up the local concurrency limit. Is qmail-send even running? Are the message staying in the todo directory? qmail-smtpd (which accepts mail over the network) is completely independent of qmail-send, which processes messages in the queue for delivery. Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
Re: paternalism silent concurrency
Thanks for the info. I've been using qmail for 3 years now and love it. It has worked great. I've never lost an email with it and it has been rock solid. Today was day two at my new job where they are rolling out a large, 5 million email a day, qmail setup. There were some issues, but with changes to disk layout and some solaris tcp tuning, testing has been promising but needs more tweaking. Is there a set or rules or tunning characteristics to watch for for large email infrastructures? Has someone written a decent paper or is there a really good book out there? The running qmail book is great but again it doesn't seem to address scalabiliy issues, etc. What I'm looking for doesn't have to be qmail specific either. Thanks. Thanks again for the help. Bob On Wed, 20 Jun 2001, Charles Cazabon wrote: -Bob C. Ruddy [EMAIL PROTECTED] wrote: - Below is the top of the output from qmail-showctl. My questions are what - is paternalism and silent concurrency? - -paternalism is the bits which are not allowed on home directories before qmail -will deliver to them. The default, 2, simply means that home directories must -not be world writable. - -The silent concurrency limit is determined by your system headers -- as I -understand it, it's a limit of how many fds can be used in a select() set, -and therefore it limits how many children qmail-lspawn and qmail-rspawn can -have at any given time. What it means is that if you try to set -concurrencylocal or concurrencyremote higher than this, it will silently be -limited to this limit. - - We are running a test now that is just testing the receiving of large - numbers of email via smtp and storing it local. What I am seeing is the - email coming it and sitting in the Q. This Q keeps gettnig larger and - larger. It seems as though there is room on the box as far as IO is - concerned. So I'd like to up the local concurrency limit. - -Is qmail-send even running? Are the message staying in the todo directory? -qmail-smtpd (which accepts mail over the network) is completely independent of -qmail-send, which processes messages in the queue for delivery. - -Charles --- -Charles Cazabon[EMAIL PROTECTED] -GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ -Any opinions expressed are just that -- my opinions. -
Re: paternalism silent concurrency
Bob C. Ruddy [EMAIL PROTECTED] wrote:
Today was day two at my new job where they are rolling out a large, 5
million email a day, qmail setup. There were some issues, but with changes
to disk layout and some solaris tcp tuning, testing has been promising but
needs more tweaking. Is there a set or rules or tunning characteristics to
watch for for large email infrastructures?
I believe Life with qmail deals a little bit with large servers; qmail.org
also has a section about them.
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:
-contract with Russell Nelson to provide _real_ advice :)
-throw Solaris in the bin. It's networking libraries are bloated and buggy,
and its filesystem performance sucks rocks.
-ensure the queue is on its own {disk, SCSI disk, 15kRPM SCSI disk, 15kRPM
SCSI RAID array)
-ensure logs are through multilog (not splogger/syslog) to a fast disk
-deliver locally to Maildirs on a NetApp Filer or similar high-performance
storage solution
-use big-todo and big-concurrency patches
-ensure you've got a dnscache running on the server for maximum DNS
performance
Charles
--
---
Charles Cazabon[EMAIL PROTECTED]
GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/
Any opinions expressed are just that -- my opinions.
---
