Wie kann ich den tatsächlichen Speicherverbrauch einer Anwendung oder eines Prozesses messen?

Question

Wie misst man den Speicherverbrauch einer Anwendung oder eines Prozesses in Linux?

In dem Blog-Artikel von Understanding memory usage on Linux ist ps kein genau richtiges Tool für diesen Zweck.

Warum ps "falsch" ist

Je nachdem, wie man es betrachtet, meldet ps nicht den tatsächlichen Speicherverbrauch von Prozessen. Was es wirklich tut, ist zu zeigen, wie viel echten Speicher jeder Prozess einnehmen würde, wenn er der einzige laufende Prozess wäre. Natürlich hat eine typische Linux-Maschine zu jedem beliebigen Zeitpunkt mehrere Dutzend Prozesse laufen, was bedeutet, dass die von ps gemeldeten VSZ- und RSS-Zahlen fast sicher falsch sind.

_{(Hinweis: Diese Frage wird <a href="https://stackoverflow.com/q/63166/15161">hier</a> sehr ausführlich behandelt.)}

Answer 1

Benutze smem, was eine Alternative zu [ps](https://en.wikipedia.org/wiki/Ps(Unix))_ ist, die USS und PSS pro Prozess berechnet. Du möchtest wahrscheinlich den PSS.

• USS - Eindeutige Speichergröße. Dies ist die Menge an ungeteiltem Speicher, die nur diesem Prozess gehört (denken Sie an U für unikalen Speicher). Er umfasst keinen gemeinsam genutzten Speicher. Daher wird dies den Betrag des Speichers eines Prozesses unterschätzen, ist jedoch hilfreich, wenn Sie den gemeinsam genutzten Speicher ignorieren möchten.

• PSS - Proportionale Speichergröße. Das ist es, was du willst. Es addiert den eindeutigen Speicher (USS) zusammen mit einem Anteil seines gemeinsam genutzten Speichers, der durch die Anzahl der Prozesse, die diesen Speicher teilen, geteilt wird. So erhalten Sie eine genaue Darstellung davon, wie viel tatsächlicher physischer Speicher pro Prozess verwendet wird - wobei der gemeinsam genutzte Speicher wirklich als gemeinsam genutzt dargestellt wird. Denken Sie an das P für physischen Speicher.

Wie sich dies im Vergleich zu RSS verhält, wie von ps und anderen Dienstprogrammen gemeldet:

• RSS - Resident Set Size. Dies ist die Menge an gemeinsam genutztem Speicher plus ungeteiltem Speicher, der von jedem Prozess verwendet wird. Wenn Prozesse Speicher teilen, wird dies den tatsächlich verwendeten Speicherbetrag überschätzen, da derselbe gemeinsam genutzte Speicher mehrmals gezählt wird - er erscheint erneut in jedem anderen Prozess, der denselben Speicher teilt. Daher ist es ziemlich unzuverlässig, besonders wenn Prozesse mit hohem Speicherverbrauch viele Forks haben - was in einem Server häufig vorkommt, mit Dingen wie Apache oder PHP (FastCGI/FPM) Prozessen.

Hinweis: smem kann auch (optional) Diagramme wie Tortendiagramme und ähnliches ausgeben. Meiner Meinung nach benötigen Sie nichts davon. Wenn Sie es einfach nur von der Befehlszeile aus wie ps -A v verwenden möchten, müssen Sie die empfohlene Abhängigkeit von Python und Matplotlib nicht installieren.

Answer 2

Es gibt keinen einfachen Weg, um dies zu berechnen. Aber einige Leute haben versucht, einige gute Antworten zu bekommen:

• ps_mem.py
• ps_mem.py bei GitHub

Answer 3

Verwenden Sie time.

Nicht das eingebaute Bash time, sondern dasjenige, das Sie mit which time finden können, zum Beispiel /usr/bin/time.

Hier ist, was es abdeckt, an einem einfachen ls:

$ /usr/bin/time --verbose ls
(...)
Zu messender Befehl: "ls"
Benutzerzeit (Sekunden): 0.00
Systemzeit (Sekunden): 0.00
Prozentsatz der CPU-Zeit für diesen Job: 0%
Verstrichene Zeit (Wanduhr) (h:mm:ss oder m:ss): 0:00.00
Durchschnittliche Größe des gemeinsam genutzten Texts (kbytes): 0
Durchschnittliche Größe ungeteilter Daten (kbytes): 0
Durchschnittliche Stackgröße (kbytes): 0
Durchschnittliche Gesamtgröße (kbytes): 0
Maximale Größe des Resident Set (kbytes): 2372
Durchschnittliche Größe des Resident Set (kbytes): 0
Haupt-(I/O erfordernde) Seitenauslagerungen: 1
Neben-(Rückgewinnen eines Rahmens) Seitenauslagerungen: 121
Freiwillige Kontextwechsel: 2
Unfreiwillige Kontextwechsel: 9
Auslagerungen: 0
Dateisystemeingaben: 256
Dateisystemausgaben: 0
Gesendete Socket-Nachrichten: 0
Empfangene Socket-Nachrichten: 0
Zugestellte Signale: 0
Seitengröße (Bytes): 4096
Exit-Status: 0

Answer 4

Neben den in den Antworten aufgeführten Lösungen können Sie den Linux-Befehl "top" verwenden. Er bietet eine dynamische Echtzeitansicht des laufenden Systems und zeigt die CPU- und Arbeitsspeicherauslastung für das gesamte System sowie für jedes Programm in Prozent an:

top

um nach einer Programm-PID zu filtern:

top -p 

Um nach einem Programmnamen zu filtern:

top | grep 

"top" bietet auch einige Felder wie:

VIRT - Virtuelles Abbild (KB): Die Gesamtmenge des vom Prozess verwendeten virtuellen Speichers

RES - Residente Größe (KB): Der nicht ausgelagerte physische Speicher, den ein Prozess verwendet hat; RES = CODE + DATA.

DATA - Daten+Stack-Größe (KB): Die Menge des physischen Speichers, der für etwas anderes als ausführbaren Code verwendet wird, auch bekannt als 'data resident set' Größe oder DRS.

SHR - Gemeinsame Speichergröße (KB): Die Menge an gemeinsam genutztem Speicher, den ein Prozess verwendet. Es spiegelt einfach den Speicher wider, der potenziell mit anderen Prozessen geteilt werden könnte.

Referenz hier.

Answer 5

Dies ist eine ausgezeichnete Zusammenfassung der Tools und Probleme: archive.org link

Ich werde es zitieren, damit es von mehr Entwicklern tatsächlich gelesen wird.

Wenn Sie den Speicherverbrauch des gesamten Systems analysieren oder den Speicherverbrauch einer Anwendung gründlich analysieren möchten (nicht nur den Heap-Verbrauch), verwenden Sie exmap. Für die Analyse des gesamten Systems finden Sie Prozesse mit dem höchsten effektiven Verbrauch, die in der Praxis den meisten Speicher nehmen, finden Sie Prozesse mit dem höchsten beschreibbaren Verbrauch, die die meisten Daten erzeugen (und daher möglicherweise undicht sind oder sehr ineffektiv in ihrer Datenverwendung sind). Wählen Sie eine solche Anwendung aus und analysieren Sie ihre Zuordnungen in der zweiten Listenansicht. Weitere Einzelheiten finden Sie im Abschnitt zu exmap. Verwenden Sie auch xrestop, um einen hohen Verbrauch von X-Ressourcen zu überprüfen, insbesondere wenn der Prozess des X-Servers viel Speicher verbraucht. Details finden Sie im Abschnitt zu xrestop.

Wenn Sie Lecks erkennen möchten, verwenden Sie valgrind oder möglicherweise kmtrace.

Wenn Sie den Heap-Verbrauch (malloc usw.) einer Anwendung analysieren möchten, führen Sie diese entweder mit memprof oder mit kmtrace aus, erstellen Sie ein Profil der Anwendung und suchen Sie im Funktionsaufrufbaum nach den größten Zuweisungen. Weitere Einzelheiten finden Sie in den entsprechenden Abschnitten.