Während das OS den Speicher kompaktiert, um große Seiten (Huge Pages) zu erzeugen, oder freien Speicher zurückgewinnt, steht der Prozess still.
Warum Freier Speicher wird knapp, oder die Funktion für große Seiten (THP) startet eine Compaction → Folge Thread, der Speicher anfordert, wartet, bis Reclaim oder Compaction fertig sind → Auf dem Bildschirm Unregelmäßige Stillstände des Servers (einige bis mehrere hundert ms)
Große Speicherzuweisungen zur Laufzeit reduzieren (beim Start vorab reservieren und wiederverwenden).
Aufgaben Infrastrukturteam
Große Seiten (THP) nur dort nutzen lassen, wo sie gebraucht werden (madvise), Schwelle für freien Speicher anheben (vm.min_free_kbytes u. a.).
Im Graphen
Vereinzelte Spitzen ohne Muster · Server-Tick-Zeit, Speicher-PSI
Wo nachsehen
some und full in /proc/pressure/memory (Anteil der Zeit, in der Tasks auf Speicher warten und stillstehen) und den Zuwachs von compact_stall in /proc/vmstat zusammen mit der Server-Tick-Zeit prüfen, Einstellung /sys/kernel/mm/transparent_hugepage/defrag kontrollieren
Spricht dafür
Zu den Tick-Spitzen steigt die Speicher-PSI, und compact_stall nimmt zu. defrag steht auf always
Spricht dagegen
PSI und compact_stall unverändert: diese Ursache scheidet aus. Steigt die Swap-Nutzung: „Swap“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen
Transparent Hugepage SupportLinux kernel Bei defrag=always werden Reclaim und Compaction direkt ausgeführt, wenn eine THP-Zuweisung scheitert, und der Prozess hält so lange an, bei madvise gilt das nur für angeforderte Bereiche
Documentation for /proc/sys/vm/Linux kernel min_free_kbytes: Mindestmenge an freiem Speicher (Watermark), die der Kernel vorhält
PSI - Pressure Stall InformationLinux kernel some (Anteil der Zeit, in der einige Tasks auf Speicher warten und stillstehen) und full (Anteil der Zeit, in der alle Tasks stillstehen) in /proc/pressure/memory