Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!ll-xn!cit-vax!mangler From: mangler@cit-vax.Caltech.Edu (System Mangler) Newsgroups: comp.unix.questions,comp.unix.wizards Subject: Re: nice values for different groups (suggestions wanted) Message-ID: <1360@cit-vax.Caltech.Edu> Date: Wed, 17-Dec-86 13:23:47 EST Article-I.D.: cit-vax.1360 Posted: Wed Dec 17 13:23:47 1986 Date-Received: Thu, 18-Dec-86 02:48:17 EST References: <4231@mit-eddie.MIT.EDU> Distribution: world Organization: California Institute of Technology Lines: 47 Summary: nice is multiplied by load average Xref: mnetor comp.unix.questions:385 comp.unix.wizards:381 In article <4231@mit-eddie.MIT.EDU>, jbs@mit-eddie.MIT.EDU (Jeff Siegal) writes: > The following applies to a 4.3BSD VAX: > > Anyway, now my question is, what are good nice values to use. What I > want to achieve is giving significant preference to users in the > higher groups when allocating CPU, without completely starving users > in the lower groups. The effect of a given nice value is multiplied by the (1-minute) load average. When the load is low, there isn't much difference between the nice values; but when the load is 10, a one-point difference in nice value can make a factor of 2 difference in CPU share. When the load average is high, the CPU share of very "nice" processes can fall to zero. Usually this happens when nice value times load average is somewhere between 60 and 100. These processes stay in an "R" state for long periods, causing the load average to remain high and reinforcing the starved-out state for itself and any additional niced processes that cron may start up, and these jobs keep accumulating and never finishing. Thus the load average soars spectacularly. This last week, when the load reached the point of starving out rnews, the load on cit-vax went up in precisely this fashion (though response for nice 0 jobs was quite good). One time we observed an impatient user taking unfair advantage of this property. He didn't want to share the CPU with the nice 4 job that had been running for hours, so he started up 20 infinite-loop processes at nice 20. With the load average up at 22 or so, everything at nice 4 or worse was completely starved out. (This raised a lot of hell). Most nice user processes are that way because it was inflicted, not chosen, and generally those are all at nice 4. The 4.2/4.3 kernel automatically does this after 10 minutes of user time (most infinite loop processes are exempted either because they're all system time, or they run as root, e.g. sendmail). itcsh automatically nices its background processes by 4, and we have some compute-bound processes (like cifplot and spice) nice themselves by 4. When the load is very high, all those nice 4 processes form a "floor" with little or no CPU falling through to nicer processes. Thus, if you don't want to risk being starved out, don't use nice values larger than 4, and referring back to the first paragraph, you probably don't want to go that far. We run Pascal compilations at nice 3, essential daemons at nice 4, and news at nice 8 through 12, with afternoon load averages of typically 4 and occasionally 10. Don Speck speck@vlsi.caltech.edu {seismo,rutgers,ames}!cit-vax!speck