Welche Speichermetrik sollten Alarme und Autoscaler für einen containerisierten Dienst verwenden: RSS, PSS, Working Set oder cgroup memory.current?

Offene Frage

Die verfügbaren Zahlen sind sich uneinig darüber, was ein Container „verbraucht“. Die Manpage definiert das VmRSS eines Prozesses als Summe von RssAnon, RssFile und RssShmem, sodass dateibasierte Seiten enthalten sind, die der Kernel reklamieren kann, und gemeinsam genutzte Seiten je Prozess einmal gezählt werden. Die cgroup-v2-Dokumentation definiert memory.current als die insgesamt aktuell von der cgroup und ihren Nachkommen verwendete Speichermenge, wobei memory.stat sie in anonymen Speicher, Datei-Cache (einschliesslich tmpfs und Shared Memory) und Kernel-Speicher aufschlüsselt; auf diese Summe reagieren memory.max und der OOM-Killer. Die Kubernetes-Dokumentation meldet Speicher als Working Set, beschreibt das Ideal als genutzten Speicher, der unter Druck nicht freigegeben werden kann, und hält fest, dass die Berechnung je nach Host-Betriebssystem variiert, stark auf Heuristiken beruht und typischerweise etwas dateibasierten Speicher einschliesst.

Welche dieser Grössen sollte für einen langlaufenden Dienst unter einem Speicherlimit einen Alarm oder einen Autoscaler steuern? Ein Alarm auf RSS kann einen Container übersehen, der sich seinem Limit nähert, weil Page-Cache und Kernel-Speicher der cgroup, aber nicht dem Prozess angelastet werden. Ein Alarm auf memory.current kann für einen Container alarmieren, dessen Cache ohnehin einfach reklamiert würde. Das Working Set liegt dazwischen, aber laut Dokumentation variiert seine Berechnung je nach Host-Betriebssystem und beruht stark auf Heuristiken. Teilfragen:

• Welches Signal wurde ein Jahr oder länger in der Praxis eingesetzt, und wie oft führte es zu falschen Alarmen im Vergleich zu verpassten OOM-Kills?
• Braucht ein Dienst, der grosse Dateien über den Page-Cache liest (Datenbanken, Medien, Log-Shipper), ein anderes Signal als einer, der seinen Zustand in anonymem Speicher hält?
• Ist die relevante Grösse überhaupt ein Stand, oder eher die Wachstumsrate des anonymen Speichers, oder die Memory-Pressure-Stall-Information, die verlorene Zeit durch Reclaim statt Bytes misst?
• Wie sollte das Signal für Dienste angepasst werden, die absichtlich Speicher bis zu einem Limit mit Cache füllen?

Was eine nützliche Antwort enthält

Die genauen Metriknamen und Quellen (welche /proc- oder cgroup-Datei, welche Laufzeitmetrik), der Workload-Typ, die Limit-Konfiguration, wie lange die Regel in Betrieb war, die Anzahl der Alarme und der OOM-Kills in diesem Zeitraum mit der Angabe, wie viele davon jeweils berechtigt waren, sowie die Begründung, die die gewählte Metrik mit der OOM-Bedingung verknüpft. Antworten, die zwei Signale am selben Dienst über denselben Zeitraum vergleichen, sind nützlicher als Antworten, die nur ein Signal beschreiben; Antworten, die lediglich Herstellervorgaben wiedergeben, sollten das kenntlich machen.