Date: Thu, 28 Jan 1999 11:29:44 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "John S. Dyson" <dyson@iquest.net> Cc: dyson@iquest.net, wes@softweyr.com, toasty@home.dragondata.com, hackers@FreeBSD.ORG Subject: Re: High Load cron patches - comments? Message-ID: <199901281929.LAA10380@apollo.backplane.com> References: <199901281915.OAA21826@y.dyson.net>
next in thread | previous in thread | raw e-mail | index | archive | help
:> at once.
:>
:> If 150 sendmails are fork instantly, the machine glitches for about
:> 2 seconds.
:>
:Is that "good enough"? Why isn't a solution that allows for really good
:sendmail performance, and also almost no glitch superior? I propose that
:it is possible to produce an almost hands free (easy to administer) mechanism
:that is quite superior to that.
:
:There are "batch" advantages to the same text pages being used over and
:over again, but the system is going to be in a CPU cache thrash state anyway
:when forking 150 sendmails. The buffer cache won't necessarily be thrashed,
:but the occupancy of data in the buffer cache is much longer anyway.
:
:--
:John | Never try to teach a pig to sing,
:dyson@iquest.net | it makes one look stupid
:jdyson@nc.com | and it irritates the pig.
Users notice load. The size of the spike doesn't matter... it's how
long it lasts that matters. I.e. I would rather a machine's load tripple
or quadruple for a few minutes then see it double for twice as long.
I would rather that *even* if I loose a little performance/efficiency.
Under normal operating conditions, it is much better to let the sendmail
burst run ASAP then it is to drag out the process by slowing down the rate
at which you allow them to be forked. Not only are you increasing the
latency that the person sending or receiving the email sees, but you
are increasing the period of time during which the machine is under a
'heavier then normal' load.
Consider a bell curve. The vertical is machine performance/efficiency,
the horizontal is resource load. You generally want to set your hard
limit such that an overload condition is placed near the peak of the
bell curve or even slightly beyond the peak -- i.e. to where the machine
is just beginning to loose efficiency. The idea is to allow the burst
load to use *all* of the machine's resources without creating a cascade
situation where the load degrades the machine to the point where it's
contributing to its own demise.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901281929.LAA10380>