steve@CHAOS.OCEAN.FSU.EDU (Steve Van Gorder) (08/08/90)
I have several problems with nice and related things. 1. The default increment for nice on my machine seems to be 4 instead of 10 as the manual says. i.e. "nice command" executes command with a nice value of 24 while "command" executes with nice=20. 2. "nice -increment command" does nothing at all for any value of increment. Its nice value is always 20 ! A question about npri. I was under the impression from previous discussions in this news group and from reading the manuals that if I type "npri -h 250 -p pid" as superuser then this process would be assigned a "non-degrading" priority of 250. According to schedctl(2) man page this means that it is of lower priority than all other processes and shouldn't interfere with ANY interactive job. It doesn't seem to work that way to me at all. In particular the window manager can become almost totally usless if there are even few jobs running in background ... and even if they have been "NPRIed" into oblivion. Shouldn't I ALWAYS see +250 as the priority in the process status table ? ... Because sometimes I do and sometimes I don't. These jobs still change priorities like all the other processes do. Anyway help with these questions will be appreciated. I have a 4D/20 with 8 meg ram running 3.2 -- Steve VanGorder steve@chaos.ocean.fsu.edu Dept. of Oceanography (128.186.3.34) Florida State University gorder@fsu.bitnet Tallahassee, Fl 32306 (904)644-2447
cschreur@ruunsa.fys.ruu.nl (Toine Schreurs) (08/08/90)
In <9008072224.AA21964@chaos.ocean.fsu.edu> steve@CHAOS.OCEAN.FSU.EDU (Steve Van Gorder) writes: >I was under the impression from previous discussions in this news group >and from reading the manuals that if I type "npri -h 250 -p pid" as superuser >then this process would be assigned a "non-degrading" priority of 250. >According to schedctl(2) man page this means that it is of lower priority than >all other processes and shouldn't interfere with ANY interactive job. >It doesn't seem to work that way to me at all. In particular the window >manager can become almost totally usless if there are even few jobs running >in background ... and even if they have been "NPRIed" into oblivion. We also have that problem, I think I know why. The processes that cause the trouble, make use of process-swapping/paging (look at ps -el, that is memory in 4096byte blocks). My first suggestion is that paging is an important system-operation, such that it is performed at a higher priority. Another suggestion is that, if you wait (reading) for about 15 seconds, the window-server process gets paged out for a significant part. I actually watched this process from a nearby terminal (ps -el). Our solution: work with a system-manager or in agreement. Suspend batch-jobs that use large amounts of memory when you need the machine interactively. -- Rob Hooft, hooft@chem.ruu.nl using someone-elses news account.
doelz@urz.unibas.ch (08/08/90)
In article <9008072224.AA21964@chaos.ocean.fsu.edu>, steve@CHAOS.OCEAN.FSU.EDU (Steve Van Gorder) writes: > > I was under the impression from previous discussions in this news group > and from reading the manuals that if I type "npri -h 250 -p pid" as superuser > then this process would be assigned a "non-degrading" priority of 250. correct. > According to schedctl(2) man page this means that it is of lower priority than > all other processes and shouldn't interfere with ANY interactive job. correct. > It doesn't seem to work that way to me at all. In particular the window > manager can become almost totally usless if there are even few jobs running > in background ... and even if they have been "NPRIed" into oblivion. .. a 'few' jobs ? There is a caveat in this kind of setup as long as you are low in CPU power and core memory. Each job still exists, as before, in memory, and , maybe, it gets swapped out once in a while. But still, there is some residual memory blocked with information needed to get the process back to life if nothing else is to be done. The memory left for the other jobs is not that much as if the were alone. > > I have a 4D/20 with 8 meg ram running 3.2 Unix takes at least about 4, and windowing will need a few more. So if you're running out of memory on a 8 megs machine, it starts swapping on its (slow) SCSI disk. Have a look at the osview and look for the length of the running queues. They could easily be too large for the PI. I have a Mac with 8 Megs RAM, and run Decnet, Ethertalk, Appletalk, TCP/IP, and TOPS. Then there is a Pagemaker, a Word, and Statview, besides Versaterm Pro and Telnet. Once in a while I had to face the fact that a MacII is just not made for such many jobs. Same applies to your PI (without wanting to compare a PI with my Mac in terms of functionality 8-( and spped :-) ... ) According to the tests we did with a 4D/20 we had about a year ago, 8 megs and 3 npri'd jobs are sufficient to make NEWS very slow. There is no chance to run Workspace on it because it takes ages. You could run ruptime and check that the load is less than 3. If you're higher, forget the PI. Our 120 (yessir, still someboxes of this kind around!) heavily drops performance once the load is larger than 6 (and it has two processors). First aid would be to npri the newsmanager to a reasonably high value (see the corresponding include file for details on npri ranges). My serious advice is to get more memory and at least a 25. Reinhard (Disclaimer: I'm not working for SGI.)
paulm@kestrel.asd.sgi.com (Paul Mielke) (08/19/90)
In article <9008072224.AA21964@chaos.ocean.fsu.edu>, steve@CHAOS.OCEAN.FSU.EDU (Steve Van Gorder) writes: > I have several problems with nice and related things. > > 1. The default increment for nice on my machine seems to be 4 instead of 10 > as the manual says. i.e. "nice command" executes command with a nice > value of 24 while "command" executes with nice=20. > > 2. "nice -increment command" does nothing at all for any value of increment. > Its nice value is always 20 ! > I have just fixed the nice(1) manual page to warn users of the csh(1) version of nice (as other posters have suggested). > A question about npri. > > I was under the impression from previous discussions in this news group > and from reading the manuals that if I type "npri -h 250 -p pid" as superuser > then this process would be assigned a "non-degrading" priority of 250. > According to schedctl(2) man page this means that it is of lower priority than > all other processes and shouldn't interfere with ANY interactive job. > The problem here is as Dr. Doelz has suggested: just because the job has lousy priority doesn't mean that it can't steal pages from other jobs when it does finally get a chance to run. In 3.3 software, we have implemented the BSD setrlimit(RLIMIT_RSS) facility. This allows the Resident Set Size (the number of pages of physical memory occupied by the process) of a process to be limited. The combination of this facility and setting a low non-degrading priority will allow you to prevent the background job from stealing resources (cpu cycles or memory pages) from higher priority processes. This facility can be used within NQS to establish batch queues that can execute large jobs that do heavy paging without dragging down the performance of interactive jobs inordinately. When you get 3.3 software, take a look at the setrlimit(2) manual entry and the 'limit' commands in csh(1). The reason that you occasionally see a priority other than +250 in the "ps -l" output for a job with "npri -h 250" is that the job will sometimes get a kernel priority temporarily while it is executing a system call in the kernel. It will revert to its +250 before leaving the kernel. If another higher priority process is on the run queue, the +250 guy will get descheduled as he unwinds out of the kernel from his syscall.
steve@CHAOS.OCEAN.FSU.EDU (Steve Van Gorder) (08/21/90)
Thanks to all who responded to my "nice" problem, especially Martin Knoblaunch
who pointed out that the nice man page assumes one is using sh and Paul
Mielke who has fixed this man page and cleared up whats going on with the
non-degrading priorities.
The best solution I've found so far to my immediate problem (of background jobs
causing the window manager to become unuseable) is to simply suspend the
offending jobs using blockproc(2) untill I go home. (hey its my machine !!)
This was pointed out by Reinhard Doelz in an earlier discussion in this news
group.
Another thing that seems to help somewhat is to use npri to set the nice value
of the news_ser all the way to 0. This seems to keep the window manager from
being paged out quite so easily and works a little better than assigning it
a non-degrading priority, I suppose since the highest available non-
degrading priority is 30 whereas as news_ser normaly has a priority of 26.
I will be very interested to see how the setrlimit facility mentioned by
Paul Mielke works in 3.3.
Most importantly, we do have additional memory in the works as suggested by
several people.
Thanks again,
--
Steve VanGorder