Dovresti usare cgroups. I punti di montaggio e i dettagli sono diversi su distribuzioni e kernel. Cioè. Debian 7.0 con kernel stock non monta cgroupfs per impostazione predefinita e ha il sottosistema di memoria disabilitato (la gente consiglia di riavviare con cgroup_enabled=memory) mentre openSUSE 13.1 viene fornito con tutto ciò che è fuori dagli schemi (a causa principalmente di systemd).
Quindi, prima di tutto, crea punti di montaggio e monta cgroupfs se non è ancora stato fatto dalla tua distribuzione:
mkdir /sys/fs/cgroup/cpu
mount -t cgroup -o cpuacct,cpu cgroup /sys/fs/cgroup/cpu
mkdir /sys/fs/cgroup/memory
mount -t cgroup -o memory cgroup /sys/fs/cgroup/memory
Crea un cgroup:
mkdir /sys/fs/cgroup/cpu/shell
mkdir /sys/fs/cgroup/memory/shell
Crea un cgroup. Ho deciso di modificare le condivisioni della CPU . Il valore predefinito per esso è 1024, quindi impostarlo su 128 limiterà cgroup all'11% di tutte le risorse della CPU, se ci sono concorrenti. Se ci sono ancora risorse CPU gratuite, queste verranno assegnate a mongodump. Puoi anche usare cpuset per limitare il numero di core disponibili.
echo 128 > /sys/fs/cgroup/cpu/shell/cpu.shares
echo 50331648 > /sys/fs/cgroup/memory/shell/memory.limit_in_bytes
Ora aggiungi i PID al cgroup, influirà anche su tutti i loro figli.
echo 13065 > /sys/fs/cgroup/cpu/shell/tasks
echo 13065 > /sys/fs/cgroup/memory/shell/tasks
Eseguo un paio di test. Python che tenta di allocare un mucchio di mem è stato ucciso da OOM:
[email protected]:~$ python -c 'l = range(3000000)'
Killed
Ho anche eseguito quattro loop infiniti e il quinto in cgroup. Come previsto, il ciclo eseguito in cgroup ha ottenuto solo il 45% circa del tempo di CPU, mentre il resto ha ottenuto il 355% (ho 4 core).
Tutte le modifiche non sopravvivono al riavvio!
Puoi aggiungere questo codice a uno script che esegue mongodump o utilizzare una soluzione permanente.
