Vous devriez utiliser des groupes de contrôle. Les points de montage et les détails sont différents sur les distributions et les noyaux. C'est à dire. Debian 7.0 avec le noyau stock ne monte pas cgroupfs par défaut et a le sous-système de mémoire désactivé (les gens conseillent de redémarrer avec cgroup_enabled=memory) tandis que openSUSE 13.1 est livré avec tout cela prêt à l'emploi (à cause de systemd principalement).
Alors tout d'abord, créez des points de montage et montez cgroupfs si cela n'a pas encore été fait par votre distribution :
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
Créez un groupe de contrôle :
mkdir /sys/fs/cgroup/cpu/shell
mkdir /sys/fs/cgroup/memory/shell
Configurez un groupe de contrôle. J'ai décidé de modifier les partages de processeur . Sa valeur par défaut est 1024, donc la définir sur 128 limitera le cgroup à 11% de toutes les ressources CPU, s'il y a des concurrents. S'il y a encore des ressources CPU libres, elles seront données à mongodump. Vous pouvez également utiliser cpuset pour limiter le nombre de cœurs disponibles.
echo 128 > /sys/fs/cgroup/cpu/shell/cpu.shares
echo 50331648 > /sys/fs/cgroup/memory/shell/memory.limit_in_bytes
Maintenant, ajoutez des PID au groupe de contrôle, cela affectera également tous leurs enfants.
echo 13065 > /sys/fs/cgroup/cpu/shell/tasks
echo 13065 > /sys/fs/cgroup/memory/shell/tasks
J'exécute quelques tests. Python qui essaie d'allouer un tas de mem a été tué par OOM :
[email protected]:~$ python -c 'l = range(3000000)'
Killed
J'ai également exécuté quatre boucles infinies et une cinquième dans cgroup. Comme prévu, la boucle exécutée dans le groupe de contrôle n'a obtenu qu'environ 45 % du temps CPU, tandis que les autres en ont obtenu 355 % (j'ai 4 cœurs).
Tous ces changements ne survivent pas au redémarrage !
Vous pouvez ajouter ce code à un script qui exécute mongodump ou utiliser une solution permanente.
