Abstract : using cgroups to limit the compiler’s greediness on the processor and disk.

Lyrics

Given:
1pc programmer,
laptop with laptop disk at 5200 rpm - 1pc,
Haskel source files 300 pcs
Coffee-script files (future JS) - 300 pcs
compilation time - 40 minutes.

Objective: to compile in the background without putting the whole system in the state of "hell and death". You can even at the cost of increasing assembly time to 50-60 minutes.
')
Decision?

cgroups

Suppose we have an approximate (by eye) disk performance in our laptop - about 80 IOPS in peak. We decide to give 40 IOPS and 300% CPU for compilation (75% of all processors).

Then everything is simple:

sudo -s mkdir -p ~/cg/io mkdir -p ~/cg/cpu mount -t cgroup -oblkio none ~/cg/io mount -t cgroup -ocpu none ~/cg/cpu mkdir ~/cg/cpu/g1 ( ) stat /dev/sda 

(we get a conclusion from which we are only interested in the Device type: 8.0 , highlighted in bold - the required one)

We run alongside the second shell, from which there will be a compilation. We look at his PID:

 echo $$ 

(get the number)

We write in the first shell:

 echo (PID   ) >~/cg/g1/cpu/tasks echo (PID   ) >~/cg/io/tasks 

(we said this, which pids and their descendants will be cut; there you can write more than one process, but for the purposes of compiling it is enough to just shell)
Further we set limits:

IO :

 echo "8:0 20" > ~/cg/io/blkio.throttle.read_iops_device echo "8:0 20" > ~/cg/io/blkio.throttle.write_iops_device 

For the device 8: 0 (see above how to recognize it), a maximum of 20 entries per second and 20 readings were set.

CPU :

 echo 300000 > ~/cg/cpu/g1/cpu.cfs_quota_us 

We set a quota of 300,000 µs (for each tick in 100,000 µs), that is, 300% CPU.

After that, we can safely run the compilation in our shell (whose PID we wrote down in the tasks) - and it will no longer eat all the available resources, slow down and beep.

Values, by the way, can be changed on the go.