2.6 KiB
\newpage
Gestion de la mémoire
Linux a une gestion de la mémoire bien particulière1 : par
défaut, malloc(3) ne retournera jamais NULL. En se basant sur l'euristique
qu'un bloc mémoire demandé ne sera pas utilisé directement et que de nombreux
process ne feront pas un usage total des blocks qu'ils ont alloués, le noyau
permet d'allouer plus de mémoire qu'il n'y en a réellement disponible. La
mémoire est donc utilisée de manière plus efficace.
Mais évidemment, cela peut donner lieu à des situations où le noyau n'est plus
en mesure de trouver de blocs physiquement disponibles, alors qu'ils avaient
effectivement été alloués au processus. Pour autant, ce n'est pas une raison
pour tuer ce processus, car il est peut-être vital pour le système (peut-être
est-ce init qui est en train de gérer le lancement d'un nouveau daemon). On
dit alors que le noyau est Out-Of-Memory.
Pour se sortir d'une telle situation, et après avoir tenté de vider les caches, il lance son arme ultime, pour retrouver au plus vite de la mémoire : l'Out-Of-Memory killer.
OOM killer
Selon un algorithme dont on raconte qu'il ne serait pas basé entièrement sur l'aléatoire2, un processus est tiré au sort (plus un processus occupe de mémoire et plus il a de chance d'être tiré au sort) par l'OOM killer. Le sort qui lui est réservé est tout simplement une mort brutale, pour permettre au système de disposer à nouveau de mémoire disponible. Si cela n'est pas suffisant, un ou plusieurs autres processus peuvent être tués à tour de rôle, jusqu'à ce que le système retrouve sa sérénité.
Esquiver l'OOM killer ?
Au sein d'un cgroup memory, les fichiers memory.oom_control (v1) ou
memory.events (v2) peuvent être utilisé afin de recevoir une notification du
noyau avant que l'OOM-killer ne s'attaque à un processus de ce groupe.
Grâce à cette notification, il est possible de figer le processus pour l'envoyer sur une autre machine. Et ainsi libérer la mémoire avant que l'OOM killer ne passe.
Jetez un œil à cet article parru sur LWN à ce sujet.
À vous de jouer {-}
Continuons l'exercice précédent où nous avions fixé les
limites de mémoire que pouvez réserver les processus de
notre groupe. Que se passe-t-il alors si memhog dépasse la quantité de
mémoire autorisée dans le cgroup ?
-
Dépendant de la valeur de
/proc/sys/vm/overcommit_memory, généralement 0. Voir https://www.kernel.org/doc/html/latest/vm/overcommit-accounting.html. ↩︎