From owner-freebsd-hackers Thu Jan 28 11:29:48 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA29003 for freebsd-hackers-outgoing; Thu, 28 Jan 1999 11:29:48 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA28995 for ; Thu, 28 Jan 1999 11:29:46 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id LAA10380; Thu, 28 Jan 1999 11:29:44 -0800 (PST) (envelope-from dillon) Date: Thu, 28 Jan 1999 11:29:44 -0800 (PST) From: Matthew Dillon Message-Id: <199901281929.LAA10380@apollo.backplane.com> To: "John S. Dyson" Cc: dyson@iquest.net, wes@softweyr.com, toasty@home.dragondata.com, hackers@FreeBSD.ORG Subject: Re: High Load cron patches - comments? References: <199901281915.OAA21826@y.dyson.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message