Alibaba Cloud Linux:Résoudre une utilisation mémoire slab_unreclaimable élevée

Symptômes

Exécutez la commande cat /proc/meminfo | grep "SUnreclaim" sur une instance Linux. Si la valeur SUnreclaim est élevée (par exemple, SUnreclaim: 6069340 kB), l'instance présente une utilisation mémoire slab_unreclaimable anormale. Lorsque slab_unreclaimable dépasse 10 % de la mémoire totale, une fuite de mémoire au niveau du slab est probable.

Cause

L'allocateur de slab du noyau met en cache des objets mémoire de taille identique afin de limiter la fragmentation. La partie slab_unreclaimable contient la mémoire que le noyau ne peut pas libérer, car elle renferme des objets actifs tels que les caches dentry et inode. Une croissance excessive de ces caches entraîne une utilisation élevée de slab_unreclaimable, susceptible de déclencher l'OOM Killer.

Solution

1. Connectez-vous à l'instance Linux.

   Pour plus d'informations, consultez Méthodes de connexion à distance aux instances ECS.

2. Identifiez le slab non récupérable présentant le plus grand nombre d'objects ou la plus forte consommation mémoire :

   1. Recherchez le slab ayant le plus d'objects ou la consommation mémoire la plus élevée.

      slabtop -s -a

      Notez le nom du slab (colonne NAME) correspondant à la valeur OBJ/SLAB la plus haute.

   2. Vérifiez si la mémoire du slab est non récupérable.

      Remplacez <slab NAME> par le nom du slab identifié à l'étape précédente comme ayant la valeur OBJ/SLAB la plus élevée.

      cat /sys/kernel/slab/<slab NAME>/reclaim_account

      Par exemple, pour vérifier si kmalloc-192 est récupérable :

      cat /sys/kernel/slab/kmalloc-192/reclaim_account

      La valeur 0 indique une mémoire non récupérable ; la valeur 1 indique une mémoire récupérable.

3. Déterminez la cause racine de la fuite de mémoire du slab.

   Utilisez l'outil crash pour une analyse statique ou l'outil perf pour une analyse dynamique. Les exemples suivants portent sur le slab kmalloc-192.

   Méthode 1 : Analyse statique avec crash

   1. Installez l'outil crash.

      sudo yum install crash -y

   2. Installez le paquet kernel-debuginfo.

      • Alibaba Cloud Linux 3

        sudo yum install -y kernel-debuginfo-<kernel version> --enablerepo=alinux3-plus-debug

        Remarque

        Remplacez kernel version par votre version de noyau réelle. Exécutez uname -r pour la vérifier.

      • Alibaba Cloud Linux 2

        sudo yum install kernel-debuginfo -y

   3. Lancez l'outil crash.

      sudo crash

   4. Consultez les statistiques mémoire pour kmalloc-192 dans crash :

      kmem -S kmalloc-192

      Pour limiter la sortie, affichez uniquement les dernières lignes. Par exemple, pour afficher les 10 dernières lignes :

      kmem -S kmalloc-192 | tail -n 10

      Exemple de sortie de commande :

          SLAB              MEMORY            NODE  TOTAL  ALLOCATED  FREE
        ffffea004c94e780  ffff88132539e000     0     42         29    13
        ffffea004cbef900  ffff88132fbe4000     0     42         40     2
        ffffea000a0e6280  ffff88028398a000     0     42         40     2
        ffffea004bfa8000  ffff8812fea00000     0     42         41     1
        ffffea006842b380  ffff881a10ace000     0     42         41     1
        ffffea0009e7dc80  ffff880279f72000     0     42         34     8
        ffffea004e67ae80  ffff881399eba000     0     42         40     2
        ffffea00b18d6f80  ffff882c635be000     0     42         42     0

      La sortie montre que ffff88028398a000 dispose de peu de mémoire FREE et d'une quantité élevée de mémoire ALLOCATED.

   5. Affichez les données mémoire pour ffff88028398a000 :

      rd ffff88028398a000 512 -S

      Si la sortie est volumineuse, affichez-la page par page.

      Si la fonction put_cred_rcu apparaît plusieurs fois dans la sortie, recherchez put_cred_rcu dans le code source du noyau Linux :

      void __put_cred(struct cred *cred)
      {
          call_rcu(&cred->rcu, put_cred_rcu);
      }

      put_cred_rcu libère de manière asynchrone la structure cred. La présence répétée de put_cred_rcu à la fin de la structure cred signale une fuite de mémoire du slab dans le noyau.

   Méthode 2 : Analyse dynamique avec perf

   1. Installez l'outil perf.

      sudo yum install perf -y

   2. Utilisez perf pour capturer la mémoire non libérée dans kmalloc-192 pendant 200 secondes :

      sudo perf record -a -e kmem:kmalloc --filter 'bytes_alloc == 192' -e kmem:kfree --filter ' ptr != 0' sleep 200

   3. Enregistrez les données capturées dans un fichier.

      Dans cet exemple, le fichier se nomme testperf.txt :

      sudo perf script > testperf.txt

   4. Consultez le fichier testperf.txt :

      cat testperf.txt

      Repérez les slabs sans mémoire free, puis retrouvez la fonction responsable dans le code source du noyau.

4. Une fois le chemin d'appel de fonction ou la structure de données du noyau à l'origine de la fuite identifié, collaborez avec les développeurs du noyau ou le personnel O&M spécialisé pour isoler la source et résoudre le problème.

   Solutions possibles :

   • Mettez à niveau le noyau ou appliquez un correctif.

   • Ajustez les paramètres du noyau.

   • Redémarrez les services ou modules affectés.

   • Optimisez les applications ou les pilotes.

   • Redémarrez le système.

Références

Les fuites de mémoire du slab réduisent la mémoire disponible, provoquent de la fragmentation et peuvent déclencher l'OOM Killer ou dégrader les performances.

• Atténuer la fragmentation de la mémoire sous Linux

• Comment résoudre une fuite de mémoire dans polkit sous Alibaba Cloud Linux 2 ?

• Dépanner l'OOM Killer