5

I'm trying to run a particular process that is using all the processor time using nice:

sudo nice -n 20 someProcess

Unfortunately, this doesn't change anything. In Activity Monitor, it's still pegging at 99% of the CPU.

I was suspicious that this might be due to the fact that there wasn't much going on, so it was perfectly able to use that much time, so I tried stress-testing with:

yes > /dev/null & yes > /dev/null & yes > /dev/null & yes > /dev/null &

Even with nice -n 20, the process in question used 99% of the CPU, pushing the four "yes" processes down from 99% to around 60% each.

I should note that I also tried using "nice" with one "yes" process similarly, and found that it made no difference at all... that "yes" process used as much processor time as all the others.

What's going on? Is "nice" broken? This was done on macOS 10.12.5.

T. Reed
  • 181
  • 1
  • 9
  • What is this mysterious process? – Mark Setchell Jun 28 '17 at 21:03
  • Does it matter, since I was able to reproduce the same thing with "yes"? I would think that using "nice" with "yes" would cause it to use less processor time than other instances of "yes", but that does not appear to be the case. – T. Reed Jun 29 '17 at 15:56
  • There are reports on SO of specific macOS processes using all the CPU - each with a different solution, so I figured it may be one of those, but if it's not something you wish to share, that's fine. – Mark Setchell Jun 29 '17 at 16:42
  • No actual help, but: (a) perhaps you have four cpu's (or eight virtual-cores)? That also jibes with having simultaneous usages of 90% and 60% x4. (b) `yes` might not be the best thing to test with, since it's I/O rather than being cpu-intensive. – not-just-yeti Aug 06 '17 at 19:11
  • Did you manage to solve your problem? I am having the same problem – Dylanthepiguy May 12 '18 at 11:04
  • Regarding my previous comment: https://unix.stackexchange.com/questions/442470/mac-10-13-4-renice-seems-to-have-no-effect?noredirect=1#comment801007_442470 – Dylanthepiguy May 12 '18 at 11:13

4 Answers4

4

Unfortunately the original poster is correct, and SEB isn't quite right.

On different OS's, processing scheduling priority can work differently.

On Windows, for example, processes with higher priority are able to exclude processes with lower priority if they ask for enough CPU. eg on a four-core system, 4 CPU-bound processes (or threads) running at "Normal" priority can completely exclude a "Below Normal" or "Low" priority CPU-bound process, but the "Low" priority process can get 100% of the CPU if nobody else wants it. I like this behavior because I can run a CPU-bound process in "Low" priority and I won't even notice it's there so long as all my other (interactive) processes run at "Normal" priority. (Assuming none of the processes eat too much RAM---that's a different story).

On all Unix systems I've worked with (including Linux), the only "priority" scheme available is the "nice" value, and it's less Draconian than the system on Windows: processes with high "nice" value can get 100% of the CPU is nothing else is using the CPU, but they will get progressively less CPU with higher niceness, but they will never be entirely excluded. For example in my experience, if I have a 4-core system and 8 CPU-bound processes, then each gets almost exactly 50% of one core if they're all at the same nice value. If, however, 4 are non-niced and 4 are niced, then the "nice'd" ones will get less and less CPU with higher and higher niceness, but they'll never be completely excluded: even at the maximum nice value of 19 (or 20 on some systems), they'll still get at least 30-40% of each core, with the non-niced ones getting about 60-70%, on average. This is different from Windows, but still reasonable.

On the other hand, so far as I can tell, on MacOS "nice" does ABSOLUTELY NOTHING. I have a 4-core Mac, and if I run 8 processes as above with half of them niced... there is absolutely no difference in the amount of CPU each of them gets. This is stupid. MacOS has completely botched it here, even though they have a "nice" program, even though the OS tells us what the nice value is ("ps -l"). In my opinion, they should either be honest and remove the functionality altogether, or add functionality so that the "nice" value actually means someething.

Note: I would be ecstatic if somebody could point out how I'm wrong, and show me if there is a way to actually reduce the CPU priority of processes I want to run in the background.

  • Yes, I have the same results on Mac OS (tested 2 years ago) while on Ubuntu everything was fine. I have to run heavy workloads and nice is good way to have "responsive" system on Linux. – Alex Feb 04 '22 at 12:51
1

The answer is "You are expecting Nice to do something that it does not do".

That isn't how Nice works. All Nice does is change the 'priority' of a process. That means that if there are two process that need CPU the one that has been 'nice'd is put in the second position rather than simply executing the processes in a FIFO manner. The parameters are all about determining what the system should schedule for the processor in what order.

So, if nothing else is requesting CPU then your 'nice'd process gets it. That means that even if ALL of the processes had been 'nice'd the CPU could still be running at 100%.

If you want a process to not push the CPU to 100% it must have built in mechanism to keep it from continually requesting that it's commands be executed. Sleeps and pauses awaiting user input, etc do this.

SEB
  • 19
  • 1
1

use renice instead of nice.

nice is for starting, renice is for one that is already running.

sudo renice -n 20 -p

0

I may be wrong but I thought the nice value had to be negative to give the highest priority to your process.

Have you tried this command: sudo nice -n -20 -p ProcessID

  • Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Mar 11 '23 at 00:23