Re^2: Increasing CPU Usage/Decreasing Run Time

Firstly, the numbers for nice work the other way round, i.e. 20 means run at the lowest priority. Secondly, this can do no good -- programs don't slow down to be awkward so that a nice priority can persuade them to hurry up or something -- there is always some other reason for it.

In this case the process is spending too much time waiting for database interactions to complete and change of priority cannot change that behaviour. But if it hadn't been that it would have been some other I/O activity.

Finally, on unix, 20 or more is equivalent to 19, which is the maximum-valued i.e. lowest priority.

One world, one people

Comment on Re^2: Increasing CPU Usage/Decreasing Run Time

Replies are listed 'Best First'.
Re^3: Increasing CPU Usage/Decreasing Run Time by hakkr (Chaplain) on Jul 26, 2005 at 09:50 UTC
I know programs don't slow down to be awkward but they do slow down if another process with a higher priority is hogging the cpu.	[reply]
Re^4: Increasing CPU Usage/Decreasing Run Time by anonymized user 468275 (Curate) on Jul 26, 2005 at 13:10 UTC
In a way, but perhaps its more accurate to think of priority as a last resort scheduling mechanism. A computer system has one or more processors each of which has only one program counter (the register that holds the address of the next instruction to be executed). Execution (=occupation of the program counter) will continue for a time slice, at which point another process is allowed in. But these days processes are likely to be waiting on I/O far more often than they are occupying memory, in which case they let other processes have their turn at a slice and are unlikely to block another process even for one turn. So in practice, it is extremely unlikely that a process will hog the CPU, unless either it is erroneously looping, which should not in any case be solved by adjusting priorities, or unless the system is truly saturated with many demanding processes, in which case only a system administrator can affect things with a negative (realtime) priority and of course he shouldn't do so, because slowing a host of processes for the sake of just one is unlikely to be desirable. Thus, what I am saying is that from a development/support perspective, process priority should also be about the last place to look for the problem. One world, one people	[reply]


Keep It Simple, Stupid
	PerlMonks