Changing the nice() value of a r
vger!willcox at urbana.mcd.mot.com
vger!willcox at urbana.mcd.mot.com
Thu Jan 26 02:14:05 AEST 1989
>2) It looks like you are running the program from a shell script. The
> "nice" command is not build in (in the bourne shell), which means you
> are now invoking twice as many processes, which aren't doing much, but
> the nice process sits waiting for the database program to finish. The
> system may start thrashing more, resulting in more idle time because
> the system is waiting for page faults. On a heavily loaded system like
> yours the cpu-usage should be close to 100%, and the higher the better.
> Lower values mean you system is thrashing.
Might I correct a couple of misconceptions here?
a) Using the nice command does NOT require any more processes. "nice"
does not run your command as a subprocess, but rather execs your
command. Leaving out many details, it does essentially:
nice (nice_value);
execvp (argv[0], argv);
b) In any reasonable system, a process that's been sitting idle will
get swapped or paged out, leaving the memory available for active
processes. Idle processes won't contribute to thrashing, and in
particular won't increase the number of page faults significantly.
(If you were constantly creating extra processes, that would
increase overhead, but that didn't appear to be the situation here.)
c) In general, I would agree that higher CPU usage is better. However,
that's only true if the CPU is spending the time doing USEFUL
work. If you can reduce overhead and thereby increase idle time,
that's good. In this case, they apparently are getting the same
amount of work done, are getting better interactive response, and
have more idle time. How could you argue that this is bad? I'd
guess that by adjusting priorities the number of process switches
has been reduced, eliminating that unnecessary overhead.
David A. Willcox
Motorola Urbana Design Center
1101 E. University Ave.
Urbana, IL 61801
217-384-8500
UUCP: ...!uiucuxc!mcdurb!willcox
ARPA: willcox at xenurus.Gould.COM (temporary mail address)
More information about the Comp.unix.wizards
mailing list