Limit cpu usage of a program

[peterw]

Limiting cpu usage is important on shared environments. I have php programs that run long and can consume too much cpu. I searched for a solution and found cpulimit.

Install cpulimit: sudo apt-get install cpulimit

Usage of cpulimit:

cpulimit -h
CPUlimit version 1.7
Usage: cpulimit TARGET [OPTIONS...]
   TARGET must be exactly one of these:
      -p, --pid=N        pid of the process
      -e, --exe=FILE     name of the executable program file
                         The -e option only works when
                         cpulimit is run with admin rights.
      -P, --path=PATH    absolute path name of the
                         executable program file
   OPTIONS
      -b  --background   run in background
      -c  --cpu=N        override the detection of CPUs on the machine.
      -l, --limit=N      percentage of cpu allowed from 1 up.
                         Usually 1 - 100, but can be higher
                         on multi-core CPUs (mandatory)
      -v, --verbose      show control statistics
      -z, --lazy         exit if there is no suitable target process,
                         or if it dies
      -h, --help         display this help and exit
 

By pid:

Find PID of program: ps ax | grep <program name>

Limit cpu to 30% for this program: cpulimit -p <PID> -l 30 &

By name:

cpulimit -P /usr/sbin/apache2 -l 30 &

By call:

cpulimit -l 30 php ~/feedimport.php & done

 

[raindog308]

Interesting.

Basically, the target process, which you can specify by pid, name, or command line, is continuosly paused and resumed by sending it SIGSTOP and SIGCONT signals.

SIGSTOP can't be trapped, so that makes sense.  

I wonder how this would work under high load (i.e., hundreds/thousands/tens of thousands of processes getting STOP/CONT continuously).

 

[Francisco]

Interesting.

Basically, the target process, which you can specify by pid, name, or command line, is continuosly paused and resumed by sending it SIGSTOP and SIGCONT signals.

SIGSTOP can't be trapped, so that makes sense.  

I wonder how this would work under high load (i.e., hundreds/thousands/tens of thousands of processes getting STOP/CONT continuously).

 Well, it spawns a cpulimit for each process, I don't know if it handles threads properly.

We had a customer in the past that was cpulimit'ing their apache instance but they forgot to add the auto expire flags (-z i think) and he had ~600 copies running pending PID's to reconnect to >_>

Francisco