Partager via

Résoudre les problèmes de consommation élevée de mémoire dans les applications nécessitant beaucoup de disques

Les opérations d’entrée et de sortie de disque sont coûteuses et la plupart des systèmes d’exploitation implémentent des stratégies de mise en cache pour lire et écrire des données dans le système de fichiers. Le noyau Linux utilise généralement des stratégies telles que le cache de pages pour améliorer les performances globales. L’objectif principal du cache de page est de stocker les données lues à partir du système de fichiers dans le cache, le rendant disponible en mémoire pour les futures opérations de lecture.

Cet article vous aide à identifier et à éviter une consommation élevée de mémoire dans les applications nécessitant beaucoup de disques en raison des comportements de noyau Linux sur les pods Kubernetes.

Conditions préalables

Outil permettant de se connecter au cluster Kubernetes, tel que l’outil kubectl . Pour effectuer l’installation kubectl à l’aide d’Azure CLI, exécutez la commande az aks install-cli .

Symptômes

Lorsqu’une application nécessitant beaucoup de disques s’exécutant sur un pod effectue des opérations fréquentes de système de fichiers, une consommation élevée de mémoire peut se produire.

Le tableau suivant présente les symptômes courants de la consommation élevée de mémoire :

Symptôme Descriptif
La métrique du jeu de travail est trop élevée. Ce problème se produit lorsqu’il existe une différence significative entre la métrique de jeu de travail signalée par l’API Métriques Kubernetes et la mémoire réelle consommée par une application.
Fin de tâche pour cause de mémoire insuffisante (OOM). Ce problème indique que les problèmes de mémoire existent sur votre pod.
Augmentation de l’utilisation de la mémoire après l’activité de disque lourd. Après les opérations telles que les sauvegardes, les lectures/écritures de fichiers volumineux ou les importations de données, la consommation de mémoire augmente.
L’utilisation de la mémoire augmente indéfiniment. La consommation de mémoire du pod augmente au fil du temps sans réduire, comme une fuite de mémoire, même si l’application elle-même ne fuite pas de mémoire.

Liste de contrôle pour la résolution des problèmes

Étape 1 : Inspecter l'ensemble de travail du pod

Pour inspecter l’ensemble de pods de travail signalé par l’API Kubernetes Metrics, exécutez la commande kubectl top pods suivante :

$ kubectl top pods -A | grep -i "<DEPLOYMENT_NAME>"
NAME                            CPU(cores)   MEMORY(bytes)
my-deployment-fc94b7f98-m9z2l   1m           344Mi

Pour obtenir des instructions détaillées sur la façon d’identifier le pod qui consomme une mémoire excessive, consultez Résoudre les problèmes de saturation de la mémoire dans les clusters AKS.

Étape 2 : Inspecter les statistiques de mémoire du pod

Pour inspecter les statistiques de mémoire des cgroups sur le pod qui consomme une mémoire excessive, procédez comme suit :

Remarque

Les groupes Cgroup permettent d’appliquer la gestion des ressources pour les pods et les conteneurs, notamment les demandes de processeur/mémoire et les limites des charges de travail conteneurisées.

  1. Connectez-vous au pod :

    $ kubectl exec <POD_NAME> -it -- bash

  2. Accédez au répertoire des statistiques et répertoriez les fichiers liés à la cgroup mémoire :

    $ ls /sys/fs/cgroup | grep -e memory.stat -e memory.current
memory.current memory.stat
    • memory.current: mémoire totale actuellement utilisée par le cgroup et ses descendants.
    • memory.stat: Cela décompose l'empreinte mémoire du cgroup en différents types de mémoire, avec des détails propres à chaque type, ainsi que d'autres informations sur l'état et les événements passés du système de gestion de la mémoire.

    Toutes les valeurs répertoriées dans ces fichiers sont en octets.

  3. Obtenez une vue d’ensemble de la façon dont la consommation de mémoire est distribuée sur le pod :

    $ cat /sys/fs/cgroup/memory.current
10645012480
$ cat /sys/fs/cgroup/memory.stat
anon 5197824
inactive_anon 5152768
active_anon 8192
...
file 10256240640
active_file 32768
inactive_file 10256207872
...
slab 354682456
slab_reclaimable 354554400
slab_unreclaimable 128056
...

    cAdvisor utilise memory.current et inactive_file pour calculer la métrique du jeu de travail. Vous pouvez répliquer le calcul à l’aide de la formule suivante :

    working_set = (memory.current - inactive_file) / 1048576 = (10645012480 - 10256207872) / 1048576 = 370 MB

Étape 3 : Déterminer la consommation de mémoire du noyau et de l’application

Le tableau suivant décrit certains segments de mémoire :

Segment Descriptif
anon Quantité de mémoire utilisée dans les mappages anonymes. La plupart des langages utilisent ce segment pour allouer de la mémoire.
file Quantité de mémoire utilisée pour mettre en cache les données du système de fichiers, notamment tmpfs et la mémoire partagée.
slab Quantité de mémoire utilisée pour stocker des structures de données dans le noyau Linux.

Combiné à l’étape 2, anon représente 5 197 824 octets, ce qui n’est pas proche du montant total signalé par la métrique du jeu de travail. Le slab segment de mémoire utilisé par le noyau Linux représente 354 682 456 octets, ce qui constitue presque toute la mémoire signalée par la métrique de l'ensemble de travail sur le pod.

Étape 4 : Supprimer le cache du noyau sur un pod de débogueur

Remarque

Cette étape peut entraîner des problèmes de disponibilité et de performances. Évitez de l’exécuter dans un environnement de production.

  1. Obtenez le nœud exécutant le pod :

    $ kubectl get pod -A -o wide | grep "<POD_NAME>"
NAME                            READY   STATUS    RESTARTS   AGE   IP            NODE                                NOMINATED NODE   READINESS GATES
my-deployment-fc94b7f98-m9z2l   1/1     Running   0          37m   10.244.1.17   aks-agentpool-26052128-vmss000004   <none>           <none>

  2. Créez un pod de débogueur à l’aide de la commande kubectl debug et créez une session kubectl :

    $ kubectl debug node/<NODE_NAME> -it --image=mcr.microsoft.com/cbl-mariner/busybox:2.0
$ chroot /host

  3. Supprimez le cache du noyau :

    echo 1 > /proc/sys/vm/drop_caches

  4. Vérifiez si la commande de l’étape précédente provoque un effet en répétant l’étape 1 et l’étape 2 :

    $ kubectl top pods -A | grep -i "<DEPLOYMENT_NAME>"
NAME                            CPU(cores)   MEMORY(bytes)
my-deployment-fc94b7f98-m9z2l   1m           4Mi

$ kubectl exec <POD_NAME> -it -- cat /sys/fs/cgroup/memory.stat
anon 4632576
file 1781760
...
slab_reclaimable 219312
slab_unreclaimable 173456
slab 392768

Si vous observez une diminution significative du jeu de travail et du slab segment de mémoire, cela indique un problème avec le noyau Linux qui utilise une grande quantité de mémoire sur le pod.

Solution de contournement : Configurer les limites et demandes de mémoire appropriées

La seule solution efficace pour une consommation élevée de mémoire sur les pods Kubernetes consiste à définir des limites et des requêtes de ressources réalistes. Par exemple:

resources:
    requests:
        memory: 30Mi
    limits:
        memory: 60Mi

En configurant les limites et demandes de mémoire appropriées dans Kubernetes ou la spécification, vous pouvez vous assurer que Kubernetes gère l’allocation de mémoire plus efficacement, ce qui atténue l’impact de la mise en cache excessive au niveau du noyau sur l’utilisation de la mémoire des pods.

Avertissement

Les limites de mémoire des pods mal configurées peuvent entraîner des problèmes tels que des erreurs OOMKilled.

références

Exclusion de responsabilité des informations tierces

Les produits tiers abordés par cet article sont fabriqués par des entreprises indépendantes de Microsoft. Microsoft ne donne aucune garantie, implicite ou autre, concernant la performance ou la fiabilité de ces produits.

Exclusion de responsabilité pour contact avec des tiers

Microsoft fournit des informations de contacts externes afin de vous aider à obtenir un support technique sur ce sujet. Ces informations de contact peuvent changer sans préavis. Microsoft ne garantit pas l’exactitude des informations concernant les sociétés externes.

Contactez-nous pour obtenir de l’aide

Si vous avez des questions, vous pouvez demander le support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.

  • Last updated on