My question was thus:
In article <1993Aug4.124440.9555@sadtler.com> I wrote:
> Question: If all other processes are running with a nice
> value of 0, does it make a difference if the background
> process runs at a nice value of 4 or 19?
Many thanks to the folks who responded. If I forgot you, thanks
too.
jdavis@cs.arizona.edu (Jim Davis)
stuckey@mrcnext.cso.uiuc.edu (Anthony J. Stuckey)
scl@virginia.edu (Steve Losen)
mark@greenwich.com (Mark Sirota)
goletz@pasp01.pava.purdue.edu (Bowen Goletz)
rjq@phys.ksu.edu (Rob Quinn)
tim@unipalm.co.uk (Tim Goodwin)
jgp@ee.rochester.edu (Jim Prescott)
rauls@usb.ve (Raul Silvera)
-----------------------------------------------------
I got definite no's and yes's. And some maybe's.
Perhaps Bowen Goletz said it best:
"Remember that process scheduling is more of a black art than a science and
your mileage will vary."
-----------------------------------------------------
Here are the edited responses...:
----No. But it's unlikely that everything else on your system really is running with a nice value of 0. For instance, if you 'nohup' a job, that job is automatically niced (typically to 10). A nice value of 19 is the largest value you can use, so _anything_ else runnable will go ahead of it. Of course that may mean the niced-to-19 job runs verrrry slowly...
----
I beleive that it does matter. The only references I could find imply that things are like this:
the highest priority process is run first. it is then placed at the end of the queue of processes with that priority. If all processes are at the same priority, this reduces to round-robin scheduling. Otherwise, at ceratin intervals, checks are made to see if a lower-priority process is available. These are similarly treated as a queue. If you are the only person running a process at low priority, then, you will only get the CPU when no one else wants it. If you are not the only person using "nice", then your 'nice +19 command' will have to wait for the 'nice command', which by default is running at nice +4.
I beleive, but couldn't find a reference for it, that checks for the existence of a +19 process are done less frequently than the existence of a +4 process.
----
The impact of your job depends on several things. If your job requires enough memory to cause the system to page, your job will probably cause interactive jobs to get paged out to disk. Since your job is computationally intensive, it is going to have much more demand for cpu than all the interactive jobs on the system. No matter how low you nice it, your job is going to be "runnable" virtually all the time while interactive jobs will spend most of their time waiting for some input event. Thus your job will get paged in, kicking out the waiting interactive jobs. Paging is terribly slow, so once an interactive user hits a key or does something to take their job out of the wait state, they get a long delay while their job gets paged back in so it can run. No matter how "nice" you make your job, it will have a dramatic and detrimental effect on interactive response.
If, however, all the jobs on the system fit in RAM, the system does not page and lowering the nice value should help somewhat. A sparc is pretty fast, so unless it is paging, I doubt that one cpu intensive job will hurt interactive response.
----
Yes, it matters. The nice value is used in a relatively complex formula for computing process priority. The higher the number, the lower the priority. So a process with a nice of 19 will get fewer CPU cycles than one with a nice value of 4, regardless of what else is running on the system.
----
Given: a) all user procs are running at a scheduling priority of zero b) the cpu is _not_ fully loaded
A process niced to 19 will still run, and if it isn't a CPU hog, will probablly still run as if it was a "0" process.
Given: a) the above, but: b) the cpu _is_ fully loaded A process niced to 19 will not run at all. Nice values from 1 to 18 will give smaller than "average" chunks of time. There are a number of programs that our network has running in the background on various workstations and servers. A process that tends to use, say, 40% of the cpu with no users, when niced to a value of 8-11, seems to behave "just right" (~10% CPU time) when there are a number of other programs wanting 15-20% CPU time.
----
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 3285 rjq 66 0 24K 140K run 0:33 52.56% 50.00% chug 3284 rjq 68 4 24K 140K run 0:26 37.82% 36.33% chug
'chug' is a simple 'for(;;);' loop. I think the missing 10% is being used by top, but I'm not sure.
Looks like about a 52:38 split for nice 0 vs nice 4. For nice 0 vs nice 19 you get about 90:2. Case closed.
----
Supposedly, 19 means "only run this process if nothing else can run", whereas values between 1 and 18 will get an occasional quantum even if the CPU is 100% busy. In practice, I've never noticed a difference, presumably because the CPU never is 100% busy.
Note that UNIX is designed so that CPU bound processes don't interfere with interactive processes as much as you might think. The priority that the scheduler assigns to each process depends on a number of factors, of which the nice value is only one (but with significant weight). Another factor is how much CPU the process has used recently; in particular, processes which run to the end of their quantum are penalised. A shell or editor that a user is typing to will always relinquish the CPU voluntarily, and thus quickly achieve a high priority.
Be careful of using nice on anything that isn't CPU bound. I believe it's possible for the scheduling and paging algorithms to interfere adversely. (I'm having trouble thinking of a watertight example though, so maybe this is just urban legend.)
----
Yes. Normal Unix scheduling prevents starvation. The longer a process stays on the ready to run queue the higher its priority gets. Nice'd processes rise in priority more slowly but they will eventually get a higher priority that a nice 0 process.
You can see this by starting several cpu-loop programs (eg main(){for(;;);} ) with varying nice values and using ps to see how they accumulate cpu time. The higher the nice value the less frequently it will run.
Also note that nice just affects cpu usage. When a background job is slowing down a system it is usually due to disk or memory usage; neither of which are affected by nice. An alternate approach that is sometimes appropriate is to use cron to send STOP and CONT signals to the process at the beginning and end of the workday.
----
Well, there is a difference. The scheduling algorithm takes into account the recent cpu usage, the nice value, and some other quantities in order to determine which process will run next. When you nice a process it doesn't means that it will not run if a higher priority process is ready, but that it will be given the cpu less often.
If you nice the process to 19, it will give to the other processes more possibilities to use the cpu than if you nice it to 4.
Conclusion: your user is right! nice your process to 19 if you are not much interested in how long it will take to run.
----
--------------------------------------- ---------------------------------------
I received some helpful hints from more than just Steve Losen, but he covered them all:
Solutions:
1) buy more RAM so that you don't page any more.
2) Run your job during hours when the interactive users aren't on (see the "at" command).
3) Suspend your job when it is causing problems and resume it later. You can suspend a job with the "kill" command. "kill -STOP PID" (where "PID" is your process id number) will stop the process. This is essentially the same as using ctrl-Z to stop a foreground job. While stopped, your job will get no cpu, will get paged out, and hence will not affect interactive response for others. To resume your job use "kill -CONT PID".
---------------------------------------
Thank you all! I learn again from the net!
-Rick. -- Rick Morris Email: rick@sadtler.com Sadtler Research Labs, Philadelphia -But I speak for myself ---------------------------------------------------------------
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:06 CDT