Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Click here to return to the 'Limit CPU usage for an application/process' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Limit CPU usage for an application/process
Authored by: S Barman on Feb 02, '11 12:09:04PM
As an old time Unix programmer, I know that this method can be dangerous! Even though signals are stacked for processes, it is possible that those processes that are not interactive that you try to control using SIGSTOP may lose track of signals. Signals are interrupts that are sent to a process when something outside of the program occurs that the process causes--such as trying to write to memory you do not have access to. SIGSTOP and SIGSTART is part of the jobs control that is usually entered from the terminal by pressing CTRL-Z. Programs designed to handle this properly should be able to process SIGSTART in order to ensure the continuation of the program properly. Many non-interactive programs are not programmed to handle SIGSTART--it is assumed that these signals are used by interactive programs and not relevant for background processes. Rather than using these signals, use the "nice" command to lower the priority of the process. Nominally, all processes start at priority 0. The priority can be set in the range of -20 (lowest) to +20 (highest). By lowering the scheduling priority you will let the underlying Mach operating system schedule other processes ahead of the one you want to limit access to CPU resources. It has the effect of lowering the scheduling priority to run the process during times when the operating system is idle, which is what you what to happen. It is a cleaner way to do what you want. There are two ways to run processes at a lower priority. First, start the process using the "nice" command.
nice -n -5 command command_arguments... &
Make sure you add the ampersand to the end of the command so that the command is run in the background. Otherwise, if you want to change the scheduling priority of a running process, use the "renice" command. Find the process identification number (pid) of the running process and run the renice command:
renice -n -5 pid
Just as you lower the scheduling priority, you can also raise the scheduling priority. However, only the superuser can raise the scheduling priority. Thus, at the end of the day if you want to reset the priority of the process back to 0 (nominal), the use "sudo" to run the renice command. Using the process's pid, run:
sudo renice 0 pid
Using "nice" and "renice" is more friendly to most running processes.

[ Reply to This | # ]
Nice does nothing to reduce thermal load
Authored by: hamarkus on Feb 02, '11 12:22:29PM

You are both right and wrong. I just had Handbrake crash on me using this script, which could be an example of the pitfalls of this method.
However, your method, ie, nice, does nothing to keep the total CPU load below 100% (per core), in fact this has already been said in the article, nice is not a solution to reduce the total CPU load.

What might work more elegantly is to simply disable one CPU core via the Developer Tools. I do not know how much this reduces the thermal load but is bound to reduce it somewhat (unless the TurboBoost kicks and completely overcompensates for this, but then you might be able to disable the TurboBoost via the developer tools as well, you might even be able to limit the CPU speed itself, I do not know.

Edited on Feb 02, '11 12:51:30PM by hamarkus

[ Reply to This | # ]
Nice does nothing to reduce thermal load
Authored by: S Barman on Feb 02, '11 01:18:49PM
Just to let you know, I did compile and run cpulimit. You need to download it from and make sure you have the latest version of the developer tools.

[ Reply to This | # ]
Nice does nothing to reduce thermal load
Authored by: hamarkus on Feb 02, '11 02:47:21PM

I tried cpulimit, checked it out and compiled it with make and ran it with: cpulimit$ ./cpulimit -l 80 -p 47879

Maybe I did not call it correctly but it did not work, ie, it did not limit my target thread to 80% CPU, cpulimit itself consumed a sizeable chunk of CPU cycles itself and something sucked up my 8 GB of memory. I did not realize this after I had quit my target thread and cpulimit itself, so I am not sure which process gobbled up all my memory, either cpulimit itself or maybe my target thread.

[ Reply to This | # ]
Limit CPU usage for an application/process
Authored by: Auricchio on Feb 02, '11 06:41:42PM

Negative numbers in nice actually allow MORE cpu usage. Positive numbers cut priority down.

EMOJO: mojo no longer workin'

[ Reply to This | # ]
Limit CPU usage for an application/process
Authored by: CoolerQ on Feb 02, '11 10:29:34PM

You're not quite right there... first off, it's SIGSTOP and SIGCONT, not SIGSTART, but I'll assume that's a typo. SIGSTOP isn't what is sent by the terminal when you press control-Z; that's SIGTSTP, which stands for "Tty SToP"; the signals are different because SIGSTOP cannot be trapped by the program you are controlling.

Your point about this interfering with the operation of some programs is, however, quite valid.

(Amusingly, Wikipedia has an article for each POSIX signal, including )

[ Reply to This | # ]