Causes et solutions de l'OOM Killer dans Alibaba Cloud Linux - Alibaba Cloud Linux

Lorsque la récupération de mémoire ne parvient pas à résoudre un manque de mémoire sur un système Linux, le noyau fait appel à l'OOM Killer pour arrêter de force les processus. Cette rubrique présente les causes courantes des événements OOM Killer sur Alibaba Cloud Linux et explique comment les résoudre.

Description du problème

Le journal suivant montre que le processus test a déclenché l'OOM Killer :

565 [Sat Sep 11 12:24:42 2021] test invoked oom-killer: gfp_mask=0x62****(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), nodemask=(null), order=0, oom_score_adj=0
566 [Sat Sep 11 12:24:42 2021] test cpuset=/ mems_allowed=0
567 [Sat Sep 11 12:24:42 2021] CPU: 1 PID: 29748 Comm: test Kdump: loaded Not tainted 4.19.91-24.1.al7.x86_64 #1
568 [Sat Sep 11 12:24:42 2021] Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS e62**** 04/01/2014

Causes possibles

Les événements OOM Killer résultent soit d'une insuffisance de mémoire globale, soit d'une insuffisance de mémoire au niveau du cgroup. Le tableau ci-dessous répertorie les scénarios courants :

Cause	Exemple de scénario
Mémoire cgroup insuffisante	Dans ce journal, l'OOM Killer se déclenche pour le cgroup `/mm_test` contenant le processus `test` : `[Wed Sep 8 18:01:32 2021] test invoked oom-killer: gfp_mask=0x240****(GFP_KERNEL), nodemask=0, order=0, oom_score_adj=0 [Wed Sep 8 18:01:32 2021] Task in /mm_test killed as a result of limit of /mm_test [Wed Sep 8 18:01:32 2021] memory: usage 204800kB, limit 204800kB, failcnt 26` Cause : le cgroup `/mm_test` a atteint sa limite de mémoire de 200 Mo.
Mémoire du cgroup parent insuffisante	Ici, le processus `test` du cgroup `/mm_test/2` est arrêté car son cgroup parent `/mm_test` a atteint sa limite de mémoire : `[Fri Sep 10 16:15:14 2021] test invoked oom-killer: gfp_mask=0x240****(GFP_KERNEL), nodemask=0, order=0, oom_score_adj=0 [Fri Sep 10 16:15:14 2021] Task in /mm_test/2 killed as a result of limit of /mm_test [Fri Sep 10 16:15:14 2021] memory: usage 204800kB, limit 204800kB, failcnt 1607` Cause : le cgroup parent `/mm_test` a atteint sa limite de 200 Mo, ce qui a déclenché l'OOM Killer sur le cgroup enfant `/mm_test/2`, même si ce dernier n'avait pas atteint sa propre limite.
Mémoire globale insuffisante	Dans ce journal, `limit of host` indique une insuffisance de mémoire globale. La mémoire libre (`free`) sur le nœud 0 est passée en dessous du filigrane bas (`low`) : `[Sat Sep 11 12:24:42 2021] test invoked oom-killer: gfp_mask=0x62****(GFP_HIGHUSER_MOVABLE\|__GFP_ZERO), nodemask=(null), order=0, [Sat Sep 11 12:24:42 2021] Task in /user.slice killed as a result of limit of host [Sat Sep 11 12:24:42 2021] Node 0 DMA32 free:155160kB min:152412kB low:190512kB high:228612kB [Sat Sep 11 12:24:42 2021] Node 0 Normal free:46592kB min:46712kB low:58388kB high:70064kB` Cause : la mémoire libre est passée en dessous du seuil minimum et la récupération de mémoire n'a pas pu libérer suffisamment de pages.
Mémoire insuffisante sur un nœud de mémoire	Indicateurs clés dans ce journal : `limit of host` indique qu'un nœud de mémoire est saturé. L'instance dispose de deux nœuds de mémoire : le nœud 0 et le nœud 1. La mémoire libre (`free`) sur le nœud 1 est inférieure à son filigrane bas (`low`). La mémoire libre totale reste élevée (`free:4111496`). [Sat Sep 11 09:46:24 2021] main invoked oom-killer: gfp_mask=0x62***(GFP_HIGHUSER_MOVABLE\|__GFP_ZERO), nodemask=(null), order=0, oom_score_adj=0 [Sat Sep 11 09:46:24 2021] main cpuset=mm_cpuset mems_allowed=1 [Sat Sep 11 09:46:24 2021] Task in / killed as a result of limit of host [Sat Sep 11 09:46:24 2021] Mem-Info: [Sat Sep 11 09:46:24 2021] active_anon:172 inactive_anon:4518735 isolated_anon: free:4111496 free_pcp:1 free_cma:0 [Sat Sep 11 09:46:24 2021] Node 1 Normal free:43636kB min:45148kB low:441424kB high:837700kB [Sat Sep 11 09:46:24 2021] Node 1 Normal: 8564kB (UME) 3758kB (UME) 18316kB (UME) 18432kB (UME) 8764kB (ME) 45128kB (UME) 16256kB (UME) 5512kB (UE) 141024kB (UME) 0 2048kB 04096kB = 47560kB [Sat Sep 11 09:46:24 2021] Node 0 hugepages_total=360 hugepages_free=360 hugepages_surp=0 hugepages_size=1048576kB [Sat Sep 11 09:46:24 2021] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB [Sat Sep 11 09:46:24 2021] Node 1 hugepages_total=360 hugepages_free=360 hugepages_surp=0 hugepages_size=1048576kB [Sat Sep 11 09:46:25 2021] Node 1 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB Cause : dans une architecture NUMA, `cpuset.mems` peut restreindre un cgroup à des nœuds de mémoire spécifiques. Si ces nœuds sont épuisés, l'OOM Killer se déclenche même lorsque d'autres nœuds disposent de mémoire libre. Exécutez cat /proc/buddyinfo pour afficher l'état des nœuds.
Mémoire insuffisante du système buddy en raison de la fragmentation de la mémoire	Indicateurs clés dans ce journal : L'OOM Killer a été déclenché lors d'une allocation `order=3` (bloc contigu de 32 Ko). La mémoire libre (`free`) sur le nœud 0 est supérieure au filigrane bas (`low`). Le système buddy ne dispose d'aucun bloc de la taille requise (`032kB (M)`). [Sat Sep 11 15:22:46 2021] insmod invoked oom-killer: gfp_mask=0x60**(GFP_KERNEL), nodemask=(null), order=3, oom_score_adj=0 [Sat Sep 11 15:22:46 2021] insmod cpuset=/ mems_allowed=0 [Sat Sep 11 15:22:46 2021] Task in /user.slice killed as a result of limit of host [Sat Sep 11 15:22:46 2021] Node 0 Normal free:23500kB min:15892kB low:19864kB high:23836kB active_anon:308kB inactive_anon:194492kB active_file:384kB inactive_file:420kB unevi ctable:0kB writepending:464kB present:917504kB managed:852784kB mlocked:0kB kernel_stack:2928kB pagetables:9188kB bounce:0kB [Sat Sep 11 15:22:46 2021] Node 0 Normal: 13254kB (UME) 9668kB (UME) 67516kB (UME) 032kB (M) 064kB 0128kB 0256kB 0512kB 01024kB 02048kB 04096kB = Cause : la fragmentation de la mémoire empêche le système buddy d'allouer un bloc contigu de la taille requise, même si la mémoire libre totale est suffisante. Remarque Le système buddy est un allocateur de mémoire du noyau Linux qui gère des blocs contigus de tailles variées afin de réduire la fragmentation.

Solutions

Résolvez le problème en fonction de sa cause.

Mémoire insuffisante dans un cgroup ou un cgroup parent

Arrêtez les processus inutiles pour libérer de la mémoire. Si votre charge de travail nécessite plus de mémoire, mettez à niveau l'instance.

Mettez à niveau l'instance.

Présentation de la modification de configuration.
Après la mise à niveau, ajustez manuellement la limite de mémoire du cgroup.
```
sudo bash -c 'echo <value> > /sys/fs/cgroup/memory/<cgroup_name>/memory.limit_in_bytes'
```
Remplacez <value> par la nouvelle limite de mémoire du cgroup en octets et <cgroup_name> par le nom de votre cgroup.

Mémoire globale insuffisante

Examinez les points suivants :

Vérifiez l'utilisation de la mémoire slab_unreclaimable.
```
cat /proc/meminfo | grep "SUnreclaim"
```
La mémoire slab_unreclaimable correspond à la mémoire que le système ne peut pas récupérer. Si elle dépasse 10 % de la mémoire totale, une fuite de mémoire slab est probable. Pour résoudre ce problème, consultez la rubrique Que faire si une instance présente un pourcentage élevé de mémoire slab_unreclaimable ?. Si le problème persiste, soumettez un ticket.
Vérifiez l'utilisation de la mémoire par systemd.
```
cat /proc/1/status | grep "RssAnon"
```
Le noyau ignore le processus 1 (systemd) lors des arrêts OOM ; l'utilisation de la mémoire par systemd ne doit donc pas dépasser 200 Mo. Si l'utilisation est anormalement élevée, mettez à jour systemd vers une version plus récente.
Examinez les performances des Transparent Huge Pages (THP).

Les THP peuvent provoquer un gonflement de la mémoire entraînant des événements OOM. Pour atténuer ce risque, ajustez les paramètres THP comme décrit dans la rubrique Comment utiliser les THP pour optimiser les performances dans Alibaba Cloud Linux ?

Mémoire insuffisante sur un nœud de mémoire

Reconfigurez cpuset.mems pour permettre au cgroup d'utiliser la mémoire de nœuds supplémentaires.

Identifiez les nœuds de mémoire de votre système.
```
cat /proc/buddyinfo
```
Configurez le paramètre cpuset.mems.
```
sudo bash -c 'echo <value> > /sys/fs/cgroup/cpuset/<cgroup_name>/cpuset.mems'
```
Remplacez <value> par les numéros des nœuds de mémoire correspondants et <cgroup_name> par le nom de votre cgroup.

Par exemple, si votre système comporte trois nœuds (nœud 0, nœud 1 et nœud 2) et que vous souhaitez que le cgroup utilise la mémoire des nœuds 0 et 2, définissez <value> sur 0,2.

Mémoire insuffisante du système buddy en raison de la fragmentation de la mémoire

Effectuez une compaction de la mémoire pendant les heures creuses :

sudo bash -c 'echo 1 > /proc/sys/vm/compact_memory'