Speicherverbrauch eines Prozesses unter Linux messen: virtuelle Grösse, RSS, PSS und was jede Kennzahl beantwortet

Ziel

Die Frage "Wie viel Speicher verbraucht dieser Prozess" mit der Kennzahl beantworten, die zur gestellten Frage passt: Passt er auf diese Maschine, gibt es ein Leck, oder wie viel kommt zusätzlich zu den bereits laufenden Prozessen hinzu.

Voraussetzungen

Linux mit Lesezugriff auf /proc/PID. Begriffe aus den Manpages: VmSize ist die virtuelle Speichergrösse und VmPeak ihr Höchstwert; VmRSS ist die Resident Set Size, die Summe aus RssAnon (anonymer Speicher), RssFile (resident abgebildete Dateien) und RssShmem (Shared Memory); VmHWM ist der Höchstwert der Resident Set Size; VmSwap ist ausgelagerter anonymer Speicher. Die Manpage kennzeichnet die RSS-Werte, VmHWM und VmSwap als ungenau und verweist auf /proc/PID/statm. In /proc/PID/smaps zeigt jede Abbildung Rss und Pss, den proportionalen Anteil des Prozesses an der Abbildung, der gemeinsam genutzte Seiten auf die daran beteiligten Prozesse verteilt; die Kernel-Dokumentation beschreibt smaps_rollup als dieselben Felder wie smaps, jedoch mit über alle Abbildungen des Prozesses summierten Werten, die sich zwar auch aus smaps ableiten liessen, aber zu deutlich höheren Kosten.

Schritte

1. /proc/PID/status lesen und VmSize, VmRSS, RssAnon, RssFile, RssShmem, VmHWM und VmSwap mit einem Zeitstempel notieren.
2. VmSize nicht für Platzentscheidungen verwenden. Es zählt reservierten Adressraum (Memory-Mapped Files, Thread-Stacks, Allocator-Arenen, den reservierten Heap einer Laufzeitumgebung), der möglicherweise nie berührt wird; Gigabytes an virtuellem Speicher bei bescheidenem RSS sind normal.
3. Für die Frage "Passt es hinein": RssAnon + VmSwap als eigene anonyme Kosten des Prozesses behandeln, RssShmem als Speicher, der belegt bleibt, solange ihn irgendein Mitnutzender hält, und RssFile als Page-Cache, den der Kernel verwerfen und neu laden kann.
4. Für die Frage "Was kommt zusätzlich hinzu" über viele Prozesse hinweg, die Bibliotheken oder ein Copy-on-Write-Elternobjekt teilen: Pss aus /proc/PID/smaps_rollup aufsummieren. Das Aufsummieren von VmRSS über mehrere Prozesse zählt jede gemeinsam genutzte Seite einmal pro Prozess.
5. Für die Frage "Gibt es ein Leck": RssAnon und VmHWM in festen Intervallen unter konstanter Last erfassen. Ein Wachstum, das nie ein Plateau erreicht, deutet auf ein Leck oder auf einen Allocator hin, der freigegebenen Speicher zurückhält; ein Plateau ist das Working Set.
6. PID, Kommandozeile, Kernel-Version, angewendete Last und die Zahlen festhalten, damit ein zweiter Durchlauf vergleichbar ist.

Erwartetes Ergebnis

Drei Zahlen mit unterschiedlicher Bedeutung für denselben Prozess: reservierter Adressraum, aktuell residenter Speicher (einschliesslich geteilter Seiten) und der proportionale Anteil. Ein Speichergraph, der kennzeichnet, welche der drei Kennzahlen er darstellt.

Grenzen und Prüfbasis

Allocators behalten freigegebenen Speicher zurück, sodass RSS lebende Objekte überschätzt; Heap-Statistiken auf Sprachebene (tracemalloc, das Heap-Profil einer Laufzeitumgebung) messen etwas anderes und sind nicht direkt vergleichbar. Memory-Mapped Files und Huge Pages erschweren die Aufteilung. Innerhalb eines Containers zählt die cgroup mehr als das RSS des Prozesses; siehe die offene Frage zu Speichermetriken von Containern. Basierend auf den zitierten Manpages; es werden keine Messwerte behauptet.