Wild thangs, was: sendmail fails to deliver mail with attachments in /var/spool/mqueue
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 10 lines · David Ford
To be honest Jeff, most of my sendmail systems have default load values and large (read created by microsoft mua) emails make it through constantly with no distinguishable delays. I just launched 45 "cat core|mail [email protected]" and core is a 10 meg binary file. It results in a 14 meg total message size.
The load spiked to .75 and dropped back to .45 while launching. I started them two minutes ago and they are all in client DATA phase with the remote MTA at the moment. I only have 30K/s upstream.
Quoted 5 lines
At present the load is .10 and the net is hopping. This isn't a power box and the rest of the system is running as well.
My guess is that the system reporting the problem has an elevated load average from those 11 modprobes stuck in D state.
They're not modprobes, they're misnamed processes sleeping from NWFS. I got the fix from someone so now they display their proper names. top displays the names correctly, ps does not. Several people have verified this problem, and all you are saying is that your servers are never heavily loaded for long periods of time, say 200 hours at a stretch of consatnt ftp traffic?
Jeff
Quoted 26 lines
I manage servers that transport hundreds of thousands of emails daily and their load is minimal. They handle large messages fine. The only defaults I've really had to change are the max children and some of the timing simply because I want stalled connections (read routing loss) to requeue quickly.
-d
Quoted 14 lines · Jeff V. Merkey
David Ford wrote:
David,
We got to the bottom of it. sendmail is using a BSD method to react to load average which is different than what linux is providing. You have to crank up
O QueueLA = 18
O RefuseLA = 12on a busy Linux server since the defaults will result in large emails never getting sent.
Quoted 8 lines
Quoted 1 line
Jeff
--
"The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'."
Content-Description: Card for David Ford
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 1 line
They're not modprobes, they're misnamed processes sleeping from NWFS.
If they're sleeping, why are they in D state? That ups the load average.
Quoted 5 lines
I got the fix from someone so now they display their proper names. top displays the names correctly, ps does not. Several people have verified this problem, and all you are saying is that your servers are never heavily loaded for long periods of time, say 200 hours at a stretch of consatnt ftp traffic?
If I had a normally expected constant load average that came very close to the sendmail configured limit, I would increase the limit. That's just common sense for an admin. Sendmail in itself doesn't affect the load average any more than any daemon does.
If your normal operating load is significant, and your configured limits are close to that, you have to expect sendmail to throttle back. It doesn't pick large emails as it's victims, everything gets throttled.
I would suspect that if you are near the limit then your disk is blocking causing a load spike which is detected by sendmail so sendmail throttles back.
In my experience, Linux (and others) can be very sluggish at a load of 2 and at another time be quite responsive w/ a load of 200. An admin should configure limits based on that machine's load history, not any given default number.
I've run sendmail for a lot of years at a lot of places. I've never seen this 'large emails aren't sent' issue that people have verified. The only reason I find valid is if the machine hovers near the limit and disk io causes the spike. That isn't sendmail's fault, it's a configuration fault.
-d
--
"The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'."
begin:vcard
n:Ford;David
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:[email protected]
title:Blue Labs Developer
x-mozilla-cpt:;14688
fn:David Ford
end:vcard
Quoted 7 lines · Jeff V. Merkey
They're not modprobes, they're misnamed processes sleeping from NWFS. I got the fix from someone so now they display their proper names. top displays the names correctly, ps does not. Several people have verified this problem, and all you are saying is that your servers are never heavily loaded for long periods of time, say 200 hours at a stretch of consatnt ftp traffic?
Kernel threads? Do this:
strcpy(current->comm, "threadname"); /* 16 char array!! */
current->mm->arg_start = current->mm->arg_end = 0; /* black magic */and `ps' should be happy.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 10 lines · Andrew Morton
Quoted 7 lines · Jeff V. Merkey
They're not modprobes, they're misnamed processes sleeping from NWFS. I got the fix from someone so now they display their proper names. top displays the names correctly, ps does not. Several people have verified this problem, and all you are saying is that your servers are never heavily loaded for long periods of time, say 200 hours at a stretch of consatnt ftp traffic?
Quoted 6 lines
Kernel threads? Do this:
strcpy(current->comm, "threadname"); /* 16 char array!! */ current->mm->arg_start = current->mm->arg_end = 0; /* black magic */and `ps' should be happy.
Even better, use sched.c:daemonize().
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/