Den Speicherverbrauch im Blick behalten mit ps_mem.py

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”

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.