Tous les produits
Search

Ce produit

    Container Service for Kubernetes:Diagnose container memory issues with SysOM

    Centre de documentation

    Container Service for Kubernetes:Diagnose container memory issues with SysOM

    Dernière mise à jour :Aug 11, 2026

    Pour remédier au manque de visibilité au niveau du moteur de conteneurs, SysOM propose une surveillance des conteneurs au niveau du noyau du système d'exploitation. Cette solution améliore l'observabilité des problèmes de mémoire et prend en charge la migration des conteneurs. Cette rubrique explique comment utiliser SysOM pour diagnostiquer les problèmes de mémoire des conteneurs, notamment en détaillant le working set au-delà des métriques standard.

    Prérequis

    Assurez-vous de disposer des éléments suivants :

    Facturation

    Lorsqu'elle est activée, la fonctionnalité ack-sysom-monitor envoie les métriques de surveillance vers Prometheus Service for Alibaba Cloud. Ces métriques sont facturées en tant que Custom Metrics et entraînent des frais supplémentaires.

    Consultez la présentation de la facturation pour Prometheus Service for Alibaba Cloud avant d'activer cette fonctionnalité. Les coûts dépendent de la taille du cluster et du nombre d'applications. Utilisez la section Resource Consumption pour surveiller l'utilisation.

    Concepts clés

    Composants de la mémoire des conteneurs

    ACK fournit une surveillance des conteneurs au niveau du noyau du système d'exploitation pour suivre avec précision l'utilisation de la mémoire et prévenir les erreurs OOM (Out Of Memory).

    La mémoire des conteneurs se divise en trois catégories :

    Catégorie Sous-catégorie Description
    Mémoire applicative Mémoire anonyme : segments de tas (heap), de pile (stack) et de données d'un processus, alloués via les appels système brk et mmap Mémoire utilisée par l'application en cours d'exécution
    Cache de fichiers : données mises en cache pour les E/S de fichiers. Le cache fréquemment accédé (ActiveFileCache) n'est pas facilement récupérable.
    Buffers : métadonnées pour les périphériques de bloc ou les systèmes de fichiers
    HugeTLB : mémoire allouée via HugePages
    Mémoire du noyau Slab : pool de mémoire pour les caches d'objets du noyau Mémoire utilisée par le noyau du système d'exploitation
    Vmalloc : alloue de grands blocs de mémoire virtuelle
    allocpage : alloue de la mémoire locale
    Autres : pile du noyau, table de pages et mémoire réservée
    Mémoire libre — Mémoire inutilisée et disponible

    Working set vs. RSS

    Kubernetes suit deux métriques de mémoire clés :

    • Working set — mémoire qu'un conteneur utilise activement : working set = inactive_anon + active_anon + active_file. Le tueur OOM (OOM killer) et Kubernetes utilisent cette valeur pour décider s'il faut expulser ou arrêter un conteneur.

    • RSS (Resident Set Size) — mémoire physique mappée dans l'espace d'adressage du conteneur, à l'exclusion du cache de fichiers. La RSS reflète la mémoire réelle de l'application, mais exclut la mémoire mise en cache que Kubernetes compte dans la limite.

    Étant donné que Kubernetes utilise le working set pour les décisions d'expulsion, le cache de fichiers peut l'augmenter silencieusement et déclencher des erreurs OOM même lorsque la mémoire de l'application est stable. SysOM décompose le working set en composants afin d'identifier le type de mémoire à l'origine du problème.

    Fonctionnement

    SysOM expose les métriques au niveau du noyau du système d'exploitation dans les tableaux de bord de Prometheus Monitoring de la console ACK. Il organise la mémoire des pods en composants du working set pour attribuer une utilisation élevée à des types de mémoire spécifiques.

    Utilisez les formules suivantes lors du diagnostic des problèmes de mémoire :

    • Total pod memory = RSS + Cache ≈ inactive_anon + active_anon + inactive_file + active_file

    • working set = inactive_anon + active_anon + active_file

    Localisez et résolvez les problèmes de mémoire des conteneurs

    Étape 1 : Ouvrez le tableau de bord SysOM

    1. Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.

    2. Sur la page Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Operations > Prometheus Monitoring.

    3. Sur la page Prometheus Monitoring, cliquez sur l'onglet SysOM, puis cliquez sur SysOM - Pods.

    Étape 2 : Identifiez le trou noir de mémoire

    1. Dans la section Pod Memory Monitor, appliquez la formule de la mémoire totale du pod pour décomposer la mémoire en cache et RSS. Examinez les proportions du cache (active_file, inactive_file, shmem) et de la RSS (active_anon, inactive_anon). Dans cet exemple, inactive_anon domine.

      image

    2. Dans la section Pod Resource Analysis, utilisez la fonction top pour identifier le pod présentant la consommation InactiveAnon la plus élevée. Dans cet exemple, arms-prom affiche la consommation la plus élevée.

      image.png

    3. Dans la section Pod Memory Details, consultez la composition de la mémoire du pod identifié. Les composants incluent Pod Cache, InactiveFile (cache de fichiers inactif), InactiveAnon (mémoire anonyme inactive) et la mémoire dirty (modifications non écrites). Utilisez ces détails pour localiser précisément le trou noir de mémoire.

      image.png

    Étape 3 : Analysez l'utilisation du cache de fichiers

    Dans la section Pod File Cache, identifiez les facteurs à l'origine d'une utilisation élevée du cache mémoire.

    Un cache de fichiers irrécupérable augmente artificiellement le working set, créant un trou noir de mémoire qui compte dans la limite de mémoire du pod et peut déclencher une expulsion ou une erreur OOM sans augmentation de la mémoire applicative.

    image.png

    Étape 4 : Résolvez le trou noir de mémoire

    Après avoir identifié le trou noir de mémoire, résolvez-le grâce à la planification fine d'ACK. Consultez la rubrique Activer la QoS de mémoire des conteneurs.

    Étapes suivantes