Um den Speicherverbrauch von Anwendungen zu messen, gibt es in Debian diverse Programme, die über den belegten Arbeitsspeicher Aufschluss geben. Teilweise wird man aber nicht richtig schlau daraus, wieviel Speicher ein Programm tatsächlich für sich allein beansprucht.
Mit htop erhält man z.B. gleich drei unterschiedliche Werte in kb VIRT, RES und SHR.
VIRT gibt dabei den virtuellen Speicherverbrauch an, welcher eine Summe aus tatsächlich belegtem und mit anderen Prozessen geteiltem Speicher ist. Zusätzlich kann auch der Inhalt einer Datei mit Hilfe von Memory Mapping direkt in den virtuellen Adressraum eines Prozesses abgebildet werden. Jeder Prozess hat seinen eigenen virtuellen Adressraum und ist dadurch von allen anderen getrennt. Kurz gesagt ist es eine Technik um die Schranken des begrenzten physikalischen Speichers zu umgehen und Prozessen Speicher dynamisch zuzuteilen, so wie er gerade benötigt wird.
Sollten also mehrere Programme die gleiche Bibliothek benötigen wird der Speicher nicht jedesmal extra neu zugeteilt sondern zwischen den Prozessen, die ihn anfordern, geteilt, worüber der Wert SHR genauer Aufschluss gibt.
RES hingegen ist die Kennzahl, die den aktuell physikalisch genutzten Speicher repräsentiert. In den meisten Fällen ist VIRT nicht der Wert, der mich interessiert, wenn ich untersuche, welches Programm gerade das System herunterzieht.
Eine ausführliche Erklärung zum Speichermanagement eines Linuxsystems gibt es im Linux Documentation Project zu lesen.
Mir ist schon beim Vergleich des Speicherverbrauchs von Ubuntu 11.04 und Debian Testing aufgefallen, dass man die Thematik nicht einfach mit dem Gnome-Systemmonitor und ein paar Zahlen erschlagen kann. Der Linuxkernel handelt auch getreu dem Motto: "Ungenutzter Speicher ist verschwendeter Speicher." So ist es auch kein Wunder, wenn sich der belegte physikalische Speicher mit der Zeit nach und nach füllt, weil Linux anfängt nicht nur Programme sondern auch aufgerufene Dateien zu cachen, was einen deutlichen Performancegewinn beschert.
Vor längerer Zeit entdeckte ich bei K.Mandla ein in Python geschriebenes kleines Skript namens ps_mem.py, welches den Speicherverbrauch von Programmen in privaten und geteilten Speicher aufteilt. Prozesse werden nicht getrennt betrachtet sondern eine Summe pro Anwendung gebildet. Klingt vielleicht anfangs verwirrend, aber mir erschien es damals als ob das Skript damit die Antwort auf die Frage liefert, wieviel RAM eine einzelne Anwendung tatsächlich einnimmt.
Um die Genauigkeit der Messergebnisse zu verbessern, lässt sich das Skript nur mit Root-Rechten und dem Befehl python ps_mem.py
ausführen. Ich empfehle daher einen kurzen Blick in den Code zu werfen, ob irgendetwas Merkwürdiges dort zu finden ist und es nicht blind zu verwenden. Mir ist bisher noch nichts besonderes aufgefallen.
Ich werde es in Zukunft dazu nutzen, um eine weitere Vergleichsmöglichkeit zu den bekannten Systemmonitoren zu haben. Eines kann man jetzt schon sagen, die Textausgabe des Skripts ist übersichtlich. Die aktuelle Ausgabe auf dem Inspiron 4000 sieht so aus.
Private + Shared = RAM used Program 4.0 KiB + 12.5 KiB = 16.5 KiB dhclient 4.0 KiB + 39.0 KiB = 43.0 KiB dbus-launch 8.0 KiB + 45.0 KiB = 53.0 KiB getty (2) 48.0 KiB + 13.5 KiB = 61.5 KiB ssh-agent 52.0 KiB + 12.5 KiB = 64.5 KiB polipo 44.0 KiB + 24.0 KiB = 68.0 KiB init 40.0 KiB + 32.0 KiB = 72.0 KiB acpid 4.0 KiB + 77.5 KiB = 81.5 KiB sshd 84.0 KiB + 24.0 KiB = 108.0 KiB sleep 4.0 KiB + 105.0 KiB = 109.0 KiB xfconfd 76.0 KiB + 36.0 KiB = 112.0 KiB cron 108.0 KiB + 10.0 KiB = 118.0 KiB .wallpaper 8.0 KiB + 110.0 KiB = 118.0 KiB su 16.0 KiB + 112.0 KiB = 128.0 KiB gvfs-gphoto2-volume-monitor 4.0 KiB + 132.5 KiB = 136.5 KiB gdm3 24.0 KiB + 130.0 KiB = 154.0 KiB gvfs-afc-volume-monitor 4.0 KiB + 160.0 KiB = 164.0 KiB polkitd 4.0 KiB + 171.0 KiB = 175.0 KiB gvfsd-trash 48.0 KiB + 128.0 KiB = 176.0 KiB gvfsd-dnssd 4.0 KiB + 182.0 KiB = 186.0 KiB gdm-session-worker 8.0 KiB + 179.0 KiB = 187.0 KiB udevd (3) 4.0 KiB + 189.5 KiB = 193.5 KiB gdm-simple-slave 148.0 KiB + 115.5 KiB = 263.5 KiB gvfsd 184.0 KiB + 85.5 KiB = 269.5 KiB gvfsd-metadata 220.0 KiB + 77.5 KiB = 297.5 KiB wpa_supplicant 180.0 KiB + 182.5 KiB = 362.5 KiB gnome-keyring-daemon 16.0 KiB + 361.0 KiB = 377.0 KiB gvfsd-network 404.0 KiB + 45.5 KiB = 449.5 KiB rsyslogd 256.0 KiB + 205.0 KiB = 461.0 KiB console-kit-daemon 244.0 KiB + 266.0 KiB = 510.0 KiB gconfd-2 392.0 KiB + 203.0 KiB = 595.0 KiB upowerd 460.0 KiB + 268.5 KiB = 728.5 KiB conky 604.0 KiB + 193.0 KiB = 797.0 KiB gvfs-gdu-volume-monitor 644.0 KiB + 248.5 KiB = 892.5 KiB udisks-daemon (2) 640.0 KiB + 381.0 KiB = 1.0 MiB dbus-daemon (2) 524.0 KiB + 613.5 KiB = 1.1 MiB notification-daemon 436.0 KiB + 796.5 KiB = 1.2 MiB python2.6 640.0 KiB + 782.5 KiB = 1.4 MiB bash (3) 1.1 MiB + 452.5 KiB = 1.5 MiB tint2 860.0 KiB + 764.5 KiB = 1.6 MiB xfce4-power-manager 1.6 MiB + 356.0 KiB = 1.9 MiB openbox 2.4 MiB + 274.5 KiB = 2.7 MiB urxvt 1.9 MiB + 1.4 MiB = 3.3 MiB leafpad 2.0 MiB + 3.2 MiB = 5.2 MiB osmo 9.0 MiB + 185.5 KiB = 9.2 MiB tor 8.8 MiB + 996.0 KiB = 9.8 MiB Xorg 7.7 MiB + 2.5 MiB = 10.3 MiB claws-mail 96.9 MiB + 4.5 MiB = 101.4 MiB midori --------------------------------- 159.9 MiB =================================
3 Replies to “Den Speicherverbrauch im Blick behalten mit ps_mem.py”