Ein kleiner Swap-Bereich mit niedriger Swappiness reduziert OOM-Kills des Hauptdienstes auf speicherknappen Servern

Hypothese

Die Kernel-Dokumentation nennt Page-Cache und anonymen Speicher als die wichtigsten freigebbaren Seitenarten, wobei anonyme Seiten nur durch Auslagern (Swapping) freigebbar sind, und beschreibt den OOM-Killer als das, was der Kernel aufruft, wenn er nicht genug Speicher freigeben kann, um weiterzuarbeiten; vm.swappiness legt die relativen Kosten fest, die der Kernel dem Auslagern gegenüber dem Verwerfen dateigestützter Seiten zuschreibt. Die Hypothese lautet: Auf Hosts, die einen Hauptdienst plus Helferprozesse (Backup-Jobs, Log-Versand, Paket-Updates) betreiben, deren Gesamtbedarf nahe am RAM liegt, gibt ein Swap-Bereich in der Grössenordnung eines Bruchteils des RAM zusammen mit einem niedrigen Swappiness-Wert dem Kernel einen Ort für selten berührte anonyme Seiten, sodass vorübergehende Lastspitzen eher in etwas Swapping als in einem OOM-Kill des grössten Prozesses enden – typischerweise des Hauptdienstes. Ohne Swap hat anonymer Speicher nirgendwohin und ist nicht freigebbar, sodass jede Spitze, die den freigebbaren Page-Cache übersteigt, in einem Kill enden muss.

Vorhersage

Über vergleichbare Zeiträume protokollieren Hosts mit der Swap-Konfiguration weniger Ereignisse «Out of memory: Killed process» für den Hauptdienst als Hosts ohne Swap, während sie rund um die Lastspitzen von null verschiedene Swap-in- und Swap-out-Zähler zeigen. Die Latenz-Perzentile des Hauptdienstes fallen in diesen Minuten auf den Swap-Hosts schlechter aus. Hosts, deren Bedarf den RAM dauerhaft und nicht nur vorübergehend übersteigt, zeigen keine Verringerung der Kills und starkes anhaltendes Swapping.

Vorgeschlagener Test

1. Paare gleich grosser Hosts nehmen, die denselben Dienst und dieselbe Last fahren; jeweils einen Host pro Paar mit Swap in Höhe eines festgelegten Bruchteils des RAM und niedrigem vm.swappiness konfigurieren, den anderen ohne Swap.
2. OOM-Kill-Ereignisse aus dem Kernel-Log, Swap-Zähler aus /proc/vmstat, MemAvailable und die Dienstlatenz mehrere Wochen lang erfassen.
3. Kill-Anzahl pro Host vergleichen, jeden Kill danach klassifizieren, ob die Lastspitze vorübergehend war, und die Latenz während der Swap-Aktivität vergleichen.
4. Mit einem Cgroup-Limit (MemoryMax= plus MemorySwapMax=) auf den Helferjobs wiederholen, um zu sehen, ob das Begrenzen der Helfer dieselbe Verringerung ohne Swap erreicht.

Status

Es wird kein Ergebnis behauptet. Die Vorhersage kann scheitern, wo die Lastspitzen der Arbeitslast grösser sind als jeder vernünftige Swap-Bereich, wo der Speicher so langsam ist, dass Swapping Health-Check-Fehlschläge verursacht, oder wo Cgroup-Limits auf den Helfern die Konkurrenz um Speicher bereits verhindern; die Hypothese betrifft nur die Kill-Häufigkeit, nicht die Gesamtleistung.