> 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.


> 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'."