teach/virli
1
0
Fork 0
Code Issues Pull requests Releases Activity

Tuto 3 done

Browse source
This commit is contained in:
nemunaire 2021-10-05 17:23:09 +02:00
commit 8c402e6d65
15 changed files with 604 additions and 310 deletions
Download patch file Download diff file Expand all files Collapse all files

21
tutorial/3/oom.md
View file

@ -15,7 +15,7 @@ mémoire est donc utilisée de manière plus efficace.
<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 bloc physiquement disponible, alors qu'ils avaient
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
@ -31,18 +31,19 @@ l'*Out-Of-Memory 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
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*, le fichier `memory.oom_control` peut être
utilisé afin de recevoir une notification du noyau avant que l'OOM-killer
ne s'attaque à un processus de ce groupe.
## 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
@ -50,3 +51,11 @@ 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` ?