Quelle métrique mémoire les alertes et les autoscalers devraient-ils utiliser pour un service conteneurisé : RSS, PSS, working set ou memory.current de cgroup ?

Question ouverte

Les chiffres disponibles ne s'accordent pas sur ce qu'un conteneur « utilise ». La page de manuel définit le VmRSS d'un processus comme la somme de RssAnon, RssFile et RssShmem, si bien qu'il inclut des pages adossées à des fichiers que le noyau peut récupérer et compte les pages partagées une fois par processus. La documentation de cgroup v2 définit memory.current comme la quantité totale de mémoire actuellement utilisée par le cgroup et ses descendants, memory.stat la décomposant en mémoire anonyme, cache de fichiers (y compris tmpfs et mémoire partagée) et mémoire noyau ; c'est sur ce total qu'agissent memory.max et le tueur OOM. La documentation de Kubernetes rapporte la mémoire sous forme de working set, décrit l'idéal comme la mémoire en cours d'utilisation qui ne peut pas être libérée sous pression, et indique que le calcul varie selon le système d'exploitation hôte, repose largement sur des heuristiques et inclut généralement une part de mémoire adossée à des fichiers.

Pour un service de longue durée soumis à une limite de mémoire, lequel de ces indicateurs devrait piloter une alerte ou un autoscaler ? Une alerte fondée sur le RSS peut manquer un conteneur qui approche de sa limite, car le cache de pages et la mémoire noyau sont imputés au cgroup mais pas au processus. Une alerte fondée sur memory.current peut déclencher une notification pour un conteneur dont le cache serait simplement récupéré. Le working set se situe entre les deux, mais la documentation indique que son calcul varie selon le système d'exploitation hôte et repose largement sur des heuristiques. Sous-questions :

• Quel signal a été utilisé en pratique pendant un an ou plus, et à quelle fréquence a-t-il produit de fausses alertes par rapport à des tueurs OOM manqués ?
• Un service qui lit de gros fichiers via le cache de pages (bases de données, médias, expéditeurs de journaux) a-t-il besoin d'un signal différent d'un service qui conserve son état en mémoire anonyme ?
• La grandeur pertinente est-elle un niveau, ou plutôt le taux de croissance de la mémoire anonyme, ou l'information de blocage par pression mémoire (memory pressure stall information), qui mesure le temps perdu en récupération plutôt que des octets ?
• Comment le signal devrait-il être ajusté pour les services qui remplissent délibérément la mémoire de cache jusqu'à une limite ?

Ce qu'une réponse utile contient

Les noms exacts des métriques et leurs sources (quel fichier /proc ou de cgroup, quelle métrique de runtime), le type de charge de travail, la configuration de la limite, la durée pendant laquelle la règle a tourné, le nombre d'alertes et de tueurs OOM sur cette période avec la proportion justifiée de chacun, et le raisonnement qui relie la métrique choisie à la condition OOM. Les réponses qui comparent deux signaux sur le même service pendant la même période sont plus utiles que celles qui décrivent un seul signal ; les réponses qui ne font que reprendre les valeurs par défaut d'un fournisseur devraient le préciser.