dan@asihub.UUCP (Dan O'Neill) (08/14/89)
When running a cpu intensive program, we have noticed that after a
while the kernel will renice the process to a lower priority. This
occurs even when no other user programs are running.
At first this phenomena was thought to occur because some background
system process needed cpu time to perform some utilitarian task.
However, the priority of our program never seems to recover to its
original state and continues to run slow.
I could use some enlightenment in the area of process scheduling and
priority under Ultrix.
This occurs on all our Ultrix machines, but for the sake of clarity,
here is a specific system configuration:
DECstation 3100, 24Meg of ram, 150Meg swap
1 RZ23 disk, 1 Rz55 disk
User files are nfs mounted from a VAX3600 server.
OS resides locally on the RZ55.
Thanks.
--
Dan O'Neill dan@asihub.uucp {uunet|ncr-sd}!asihub!dan
Automated Systems, Inc. San Diego R&Drusty@GARNET.BERKELEY.EDU (08/15/89)
The renicing of long running processes is a crude hack put in by the Berkeley people in 4bsd to attempt to improve interactive response at the expense of cpu intensive programs which at that time on their system probably consisted of troff jobs and such. The algorithm in 4bsd is essentially "if the process isn't being run by root and its niceness isn't between 0 and 4 then renice it to 4." Therefore, you can either renice it to some negative value (-1 for example) or 1, 2, or 3, or have root start it. Remember that niceness only affects things when more than 1 process is running (R under the STAT column from the output of ps; all the others don't count for the most part). If only 1 process is running and it's at nice 20 it runs at full spead (i.e., it gets 100% of the cpu).
rusty@garnet.berkeley.edu (08/16/89)
In article <8908150138.AA24829@garnet.berkeley.edu> rusty@GARNET.BERKELEY.EDU writes:
From: rusty@GARNET.BERKELEY.EDU
Newsgroups: comp.unix.ultrix
Subject: Process scheduling - how does it work.
Date: 15 Aug 89 01:38:41 GMT
The renicing of long running processes is a crude hack put in by the
Berkeley people in 4bsd to attempt to improve interactive response at
the expense of cpu intensive programs which at that time on their
system probably consisted of troff jobs and such. The algorithm in
4bsd is essentially "if the process isn't being run by root and its
niceness isn't between 0 and 4 then renice it to 4." Therefore, you
can either renice it to some negative value (-1 for example) or 1, 2,
or 3, or have root start it.
Make that "... and its niceness isn't 0 or 4". (That's what I meant
by crude.)
--
--------------------------------------
rusty c. wright
rusty@violet.berkeley.edu ucbvax!violet!rustygregg@cbnewsc.ATT.COM (gregg.g.wonderly) (08/16/89)
From article <8908150138.AA24829@garnet.berkeley.edu>, by rusty@GARNET.BERKELEY.EDU: > Remember that niceness only affects things when more than 1 process is > running (R under the STAT column from the output of ps; all the others > don't count for the most part). If only 1 process is running and it's > at nice 20 it runs at full spead (i.e., it gets 100% of the cpu). If only one process is running at any nice, it gets 100% of the CPU. The nice value appears to be set by your shell. Several versions of the Bourne/C/Korn shells have added the automated (some are setable) nicing of processes when the '&' is used to start them up in the background. For a quick try at a solution, try sh -c 'old-command' which will run that command under the bourne shell instead. I used this on a system with the C-shell where I did not want 'nohup' in effect for a process that I started in the background. -- ----- gregg.g.wonderly@att.com (AT&T bell laboratories)