62 lines
2.6 KiB
Markdown
62 lines
2.6 KiB
Markdown
\newpage
|
|
|
|
Gestion de la mémoire
|
|
=====================
|
|
|
|
Linux a une gestion de la mémoire bien particulière[^vm-overcommit] : 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.
|
|
|
|
[^vm-overcommit]: 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>.
|
|
|
|
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éatoire[^oom-algo], 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é.
|
|
|
|
[^oom-algo]: <https://linux-mm.org/OOM_Killer>
|
|
|
|
|
|
## 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](https://lwn.net/Articles/590960/) à
|
|
ce sujet.
|
|
|
|
|
|
## À vous de jouer {-}
|
|
|
|
Continuons l'exercice précédent où nous avions [fixé les
|
|
limites](#Fixer-des-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` ?
|