Date: Thu, 28 Jan 1999 19:26:14 -0500 (EST) From: "John S. Dyson" <dyson@iquest.net> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: dyson@iquest.net, wes@softweyr.com, toasty@home.dragondata.com, hackers@FreeBSD.ORG Subject: Re: High Load cron patches - comments? Message-ID: <199901290026.TAA22366@y.dyson.net> In-Reply-To: <199901281929.LAA10380@apollo.backplane.com> from Matthew Dillon at "Jan 28, 99 11:29:44 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon said: > :> 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. > Isn't it more the lack of responsiveness that matters? I mean, it is the missing shell prompt, more than the long term amount of CPU that they can get, right? If the scheduler is good, the users will notice load only as a longer term artifact, but short term, the realtime response is still snappy. By providing a sluggish behavior for trivial operations, there is obviously a bias against them, since the trivial operations often don't even use up their quantum, and many of those operations take much less time to run, than the delay imposed due to system loading conditions. Quantifying load as being "double" depends on the measurement method. Note that "loadaverage" as a load isn't very useful for short term responsiveness. By specifying the goals for the scheduler (end user requirements), it is quite possible to maintain a responsive shell, while a system is very heavily loaded in the traditional loadaverage sense. It is also possible to have a heavily loaded system (short term), while the system appears to be lightly loaded in a loadaverage sense. The above issues are true for the CPU scheduler, but there are such issues for other items (like paging rates or memory) also. -- 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. 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?199901290026.TAA22366>