RE: [Mimedefang] Mimedefang errors: What might be the cause?
Quoting Gary Funck [EMAIL PROTECTED]: From cf/README: confQUEUE_LAQueueLA [varies] Load average at which queue-only function kicks in. Default values is (8 * numproc) where numproc is the number of processors online (if that can be determined). confREFUSE_LA RefuseLA[varies] Load average at which incoming SMTP connections are refused. Default values is (12 * numproc) where numproc is the number of processors online (if that can be determined). For dedicated mail servers, the value of RefuseLA should be **greater** than the value of QueueLA. [snip] Hence RefuseLA should be **lower** than QueueLA, the number of daemon children should probably be lower than the number of queue runnners (MaxChildren vs. MaxQueueChildren). On a dedicated mail server, you want to set QueueLA *higher* than RefuseLA - the other way around will cause your queue to explode when the load is high [snip] The default of QueueLA lower than RefuseLA only makes sense for a server that does other things besides mail [snip] So which is it?? RefuseLA QueueLA ?? or QueueLA RefuseLA ?? should it be greater/higher or lower ?? Meni ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Mimedefang errors: What might be the cause?
Kris Deugau wrote: define(`confQUEUE_LA', `2')dnl define(`confREFUSE_LA', `7')dnl Bad settings. Having REFUSE_LA higher than QUEUE_LA is a surefire way to kill your server. Most busy SMTP servers are I/O bound, and running in queue-only mode does nothing to reduce your I/O load. In fact, it *increases* it because the messages will need to be pulled from the queue at some point in the future. See Sendmail Performance Tuning by Nick Christenson. If you're running Linux, and those settings work well from you, your mail server is *not* busy! :-) Regards, David. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Mimedefang errors: What might be the cause?
From:David F. Skoll Sent: Monday, January 16, 2006 8:58 AM Kris Deugau wrote: define(`confQUEUE_LA', `2')dnl define(`confREFUSE_LA', `7')dnl Bad settings. Having REFUSE_LA higher than QUEUE_LA is a surefire way to kill your server. Some handy tuning/debugging tips: http://www.brandonhutchinson.com/Miscellaneous_Sendmail_notes.html Quoting: rejecting connections on daemon MTA By default, Sendmail will reject MTA/MSA connections when the system load is 12 * number of processors, and operate in queue-only mode when system load is 8 * number of processors. egrep QueueLA|RefuseLA /etc/mail/sendmail.cf #O QueueLA=8 #O RefuseLA=12 From cf/README: confQUEUE_LAQueueLA [varies] Load average at which queue-only function kicks in. Default values is (8 * numproc) where numproc is the number of processors online (if that can be determined). confREFUSE_LA RefuseLA[varies] Load average at which incoming SMTP connections are refused. Default values is (12 * numproc) where numproc is the number of processors online (if that can be determined). For dedicated mail servers, the value of RefuseLA should be greater than the value of QueueLA. Mail should not be accepted faster than it can be processed, as mentioned in sendmail/TUNING: It is important not to accept mail faster than it can be delivered otherwise the system will be overwhelmed. Hence RefuseLA should be lower than QueueLA, the number of daemon children should probably be lower than the number of queue runnners (MaxChildren vs. MaxQueueChildren). Also, read this comp.mail.sendmail post http://groups.google.com/group/comp.mail.sendmail/msg/41d65caec2a4edb3?hl=en lr=ie=UTF-8 On a dedicated mail server, you want to set QueueLA *higher* than RefuseLA - the other way around will cause your queue to explode when the load is high (assuming you reach QueueLA of course), you accept lots of new messages but can't get rid of them as the load average hovers around RefuseLA - the many messages in the queue drive up disk I/O and thereby the load average. The default of QueueLA lower than RefuseLA only makes sense for a server that does other things besides mail, where you want to reduce the impact of the mail load on the other functions by queuing instead of delivering when the load is high. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Mimedefang errors: What might be the cause?
David F. Skoll wrote: Kris Deugau wrote: define(`confQUEUE_LA', `2')dnl define(`confREFUSE_LA', `7')dnl Bad settings. Having REFUSE_LA higher than QUEUE_LA is a surefire way to kill your server. Most busy SMTP servers are I/O bound, and running in queue-only mode does nothing to reduce your I/O load. In fact, it *increases* it because the messages will need to be pulled from the queue at some point in the future. See Sendmail Performance Tuning by Nick Christenson. If you're running Linux, and those settings work well from you, your mail server is *not* busy! :-) *shrug* It's not as heavily loaded as it was at one point; most of the real load was peaky; and accepting and queuing mail was the better tradeoff than refusing outbound mail connections from customers. :/ (I *did* try it the other way around for a while, but refusing connections first causes phone calls asking why $customer can't send email.) Every so often the load spikes to ~12 or so - usually late at night when the only mail showing up is inbound mail^Wspam to hosted domains. It's an all-in-one domain hosting box, so other processes affected mail processing too. On another system I had them set to queue at 1 and refuse at 8, IIRC; for a time it was accepting relay mail from a qmail box that kept opening *hordes* of parallel connections. It suffered from the same problem with customer's outbound mail, along with complaints about delayed *inbound* mail. Queuing the mail meant that, on the whole, mail got delivered faster. Addition of RBL checks on the qmail system has dropped the number of relayed messages by ~80% or so. (All spam.) Ah, legacy systems. g Both are to be retired, neither is misbehaving, and the load on each slowly drops as customers cancel their service. -kgd ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Mimedefang errors: What might be the cause?
On Mon, Jan 16, 2006 at 11:57:56AM -0500, David F. Skoll wrote:
define(`confQUEUE_LA', `2')dnl
define(`confREFUSE_LA', `7')dnl
Bad settings.
Having REFUSE_LA higher than QUEUE_LA is a surefire way to kill your server.
Most busy SMTP servers are I/O bound, and running in queue-only mode does
nothing to reduce your I/O load. In fact, it *increases* it because the
... unless your mailserver's main role is to deliver the messages on
a large NFS attached storage. Then when the storage has temporary
performance issues, it helps to offload it into the queue temporarily.
Provided your local disks are fast enough, of course. That's why we have
QUEUE_LA slightly lower than REFUSE_LA on our incoming mail servers...
The original poster also mentioned:
define(`confDELAY_LA', `2')dnl
Ouch. It might be instructive to read some sendmail source that is
related to DelayLA... sendmail not only delays for one second after
each command, but also sleeps N seconds before accept()ing each new
connection, where N is the number of listening ports.
I tried it once, on a server where we happened to have 6 listening
sockets, and the results were nothing short of disastrous because
we have WAY more incoming connections than 1 per 6 seconds. Your usual
N is 2 or 3 (for ports 25, 465 and 587 (smtp, smtps and submission)),
so if you expect more than one connection every 2 or 3 seconds (that's
30 or 20 new connections per minute), then you should seriously
reconsider your use of DELAY_LA.
--
#!perl -wpl # mmfppfmpmmpp mmpffm [EMAIL PROTECTED]
$p=3-2*/[^\W\dmpf_]/i;s.[a-z]{$p}.vec($f=join('',$p-1?chr(sub{$_[0]*9+$_[1]*3+
$_[2]}-(map{/p|f/i+/f/i}split//,$)+97):qw(m p f)[map{((ord$)%32-1)/$_%3}(9,
3,1)]),5,1)='`'lt$;$f.eig;# Jan-Pieter Cornet
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Mimedefang errors: What might be the cause?
Jan Pieter Cornet wrote: The original poster also mentioned: define(`confDELAY_LA', `2')dnl Ouch. It might be instructive to read some sendmail source that is related to DelayLA... sendmail not only delays for one second after each command, but also sleeps N seconds before accept()ing each new connection, where N is the number of listening ports. Yep. I haven't read the source and I don't recall anything WRT extra padding for multiple ports, but I'm aware of that backoff. That was very deliberate; I *do* *not* want to reach RefuseLA on that box because doing so will cause customer phone calls complaining that they can't send email. :( At the time I was tuning that system, new hardware was Not An Option, and since then the general load has dropped. It kept mail flowing - albeit slowly... even during a minor spam storm, or during one of the other make Kris unhappy events that bit that machine. All that does is to slow down the operation of sending email; under the (legitimate) usage and with the marginal hardware available, that was preferable to rejecting customer SMTP connections. I don't think I even hit that limit very hard ever; and even now about the only things likely to hit it are spammers and their ratware. g -kgd ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Mimedefang errors: What might be the cause?
On 14/01/06, Lisa Casey [EMAIL PROTECTED] wrote: Hi, I'm running Mimedefang/Spamassassin on a Redhat server with Sendmail. This has all been running fine for a couple of years now. Suddenly, this morning my customers were unable to send e-mail. Looking at /var/log/maillog, I saw lots of entries such as this: Jan 14 02:22:18 Raydeus-Dee mimedefang-multiplexor[1014]: No free slaves ---SNIP signs of a busy mail server--- I need to try to determine what might cause this and how to prevent it from happening again. Likely you had more incoming connections than configured slaves. Also - how do I find out how many slaves Mimedefang is configured to have and should I increase that? If so, how? Check your startup script. -- Please keep list traffic on the list. Rob MacGregor Whoever fights monsters should see to it that in the process he doesn't become a monster. Friedrich Nietzsche ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Mimedefang errors: What might be the cause?
From: Lisa Casey Sent: Saturday, January 14, 2006 8:16 AM I'm running Mimedefang/Spamassassin on a Redhat server with Sendmail. Which versions? What sort of hardware (cpu type, speed, memory size) How many average messages/day? This has all been running fine for a couple of years now. Suddenly, this morning my customers were unable to send e-mail. Looking at /var/log/maillog, I saw lots of entries such as this: Jan 14 02:22:18 Raydeus-Dee mimedefang-multiplexor[1014]: No free slaves Jan 14 02:22:18 Raydeus-Dee mimedefang-multiplexor[1014]: No free slaves Unless you have a very active night shift, 2AM is not a typical time to expect a mail overload. Couple of things to check: 1. disk space: try 'df -h' and note if any file systems are full or near full. Especially the one that /tmp lives on. 2. check your version of SA. Versions 3.0.0 through 3.0.3 are subject to Denial of Service attacks. 3. Try running, 'md-mx-ctrl rawstatus', and check 'man md-mx-ctrl' for an explanation of the results. With some work, you could write a cron script that tails /var/log/maillog and looks for the 'no free slaves' and have it run some combination of 'top -b | head -20', 'md-mx-ctrl rawstatus' and any other commands that can give you some info. on what might be going on. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Mimedefang errors: What might be the cause?
Try running, 'md-mx-ctrl rawstatus' 'md-mx-ctrl load' is also useful, and human readable. The various other commands described in 'man md-mx-ctrl' may also help provide some insight into what is going on. For example, 'md-mx-ctrl slaveinfo 0' will tell you which pid is assigned to slave 0. Then you can run 'strace -ppid' to follow the system calls it makes and try to understand where it may be running aground. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Mimedefang errors: What might be the cause?
Hi, Also - how do I find out how many slaves Mimedefang is configured to have and should I increase that? If so, how? Check your startup script. I looked in the startup script: /etc/init.d/mimedefang The only things in there that have to do with slaves are: # MX_SLAVE_DELAY=3 # MX_MIN_SLAVE_DELAY=0 # MX_LOG_SLAVE_STATUS_INTERVAL seconds # MX_LOG_SLAVE_STATUS_INTERVAL=30 # MX_STATUS_UPDATES=yes # MX_MAX_RSS=1 # MX_MAX_AS=3 Quite honestly none of these look like settings I could tweak to increase the maximum number of slaves. In my maillog I have this: Jan 14 10:40:23 Raydeus-Dee mimedefang-multiplexor[1211]: started; minSlaves=2, maxSlaves=10, maxRequests=500, maxIdleTime=300, busyTimeout=600, clientTimeout=10 and I think the maxSlaves looks like it is low to me. By the way, I'm using RedHat 7.2, mimedefang version 2.48, and SpamAssassin version 3.0.1 running on Perl version 5.8.5 (I'm basically using MimeDefang to run Spamassassin). Guess I need more help then this to increase maxSlaves. Sorry. Lisa Casey ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Mimedefang errors: What might be the cause?
On Sat, 14 Jan 2006, Lisa Casey wrote: Hi, Also - how do I find out how many slaves Mimedefang is configured to have and should I increase that? If so, how? Check your startup script. I looked in the startup script: /etc/init.d/mimedefang The only things in there that have to do with slaves are: # MX_SLAVE_DELAY=3 # MX_MIN_SLAVE_DELAY=0 # MX_LOG_SLAVE_STATUS_INTERVAL seconds # MX_LOG_SLAVE_STATUS_INTERVAL=30 # MX_STATUS_UPDATES=yes # MX_MAX_RSS=1 # MX_MAX_AS=3 Quite honestly none of these look like settings I could tweak to increase the maximum number of slaves. In my maillog I have this: Jan 14 10:40:23 Raydeus-Dee mimedefang-multiplexor[1211]: started; minSlaves=2, maxSlaves=10, maxRequests=500, maxIdleTime=300, busyTimeout=600, clientTimeout=10 and I think the maxSlaves looks like it is low to me. By the way, I'm using RedHat 7.2, mimedefang version 2.48, and SpamAssassin version 3.0.1 running on Perl version 5.8.5 (I'm basically using MimeDefang to run Spamassassin). Guess I need more help then this to increase maxSlaves. Sorry. Are MX_MINIMUM and MX_MAXIMUM set to the defaults? It's says in my config file (/etc/sysconfig/mimedefang) that The default value of 2 is probably too low. I set them as follows: MX_MINIMUM=4 MX_MAXIMUM=30 I got the same errors as you when my machines were under load and bumping these values made everything happy happy. -rick Lisa Casey ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
