Date: Thu, 28 Jan 1999 14:52:41 -0500 (EST) From: "John S. Dyson" <dyson@iquest.net> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: dillon@apollo.backplane.com, dyson@iquest.net, wes@softweyr.com, toasty@home.dragondata.com, hackers@FreeBSD.ORG Subject: Re: High Load cron patches - comments? Message-ID: <199901281952.OAA21912@y.dyson.net> In-Reply-To: <199901281920.LAA10349@apollo.backplane.com> from Matthew Dillon at "Jan 28, 99 11:20:36 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon said: > Since I'm using sendmail a little too much as an example, I'll use BEST's > web server as another example. > > The web server hard limits the number of simultanious connections. On > a relatively loaded machine, say shell5.ba.best.com, the peak utilization > is fairly consistent. The monday-noon peak runs at 35 hits/sec and > 500 simultanious established connections. > > We set the hard limit to around 800 simultanious established connections. > In this case, it appears that you have established a value by measuring it. Then you have set a threshold a little higher than the maximum expected. In this case, you can effectively apply a "hard" limit. The situation that I have been thinking of are the indeterminate or unforseeable circumstances where applications produce a varying load (perhaps timeshared or perhaps workstation.) There are cases where a properly behaved application will perhaps page or somesuch. You cannot apriori determine these circumstances, but you can know that you have a limited amount of I/O bandwidth for paging. Given you don't want a single process to terribly hog the system, and you really don't know how many processes or how much memory will need to be paged (due to the varying load), then a way of estimating the system capability and apportion it so that the "hog" still runs, but the rest of the applications run nicely is advantageous. There are indeed cases where it is advantageous from a batch standpoint to run a single process type in a burst, but there are also tradeoffs as to other service types. IMO, it seems that shell type operations (interactive shells, editors, etc) are a form of soft realtime. By limiting the amount (in a relative sense) of time that a "batch" process takes from a CPU, the realtime processes still run nicely. In a normal scheduling situation, one would not always want to impose the limit, because otherwise the resource might be wasted if not used. Most of the real limits are rates (except for memory), and of course, by setting static occupancy (or connection) limits, certain rate limits will be effective. I think that a real challenge for OS developers is to produce a system that will tune itself without magic parameters. Of course, one cannot tune without knowing what the criteria are -- it doesn't make any difference if it is the OS that applies the policy, or a sysop that applies the policy. One has to define the policy first. In timesharing, there are both realtime and batch goals. The current scheduler works really well for CPU apportionment in alot of applications. One problem current is that CPU is about the only thing scheduled, but other things can be effectively scheduled and shared, without untoward impact. Setting arbitrary vm limits (for example) by the OS developers is alot like setting a CPU limit for a scheduler. Imagine a scheduler that is tuned to support a CPU the speed of a 386. Then, when you upgrade to a P5 or P6, you still get the performance of a 386, until you retune the system :-). It is absurd, because CPU schedulers are pretty well developed. However, CPU isn't the limiting resource much anymore, and other things are a limiting resource (net bandwidth, disk bandwidth/latency, etc.) Rather than visiting the limits one-by-one, a general scheduling/fairness mechanism seems in order. By default, it could work just like it does today, but other fairness behaviors could be provided, and automatically scaled. -- 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?199901281952.OAA21912>