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
=================================

Teste dein Multi-Boot System

Wie findet man heraus, welche Linuxdistribution die „bessere“ ist? In was besser eigentlich und wie misst man am besten?

Natürlich braucht man geeignete Werkzeuge und Irgendetwas, mit dem sich die Ergebnisse vergleichen lassen.

In meinem Beitrag zu Speicherverbrauch und Compiz von Ubuntu 11.04, habe ich versucht es etwas lockerer mit dem Systemmonitor und etwas Gefühl zu versuchen.

Für großangelegte Benchmarks gibt es für Linux aber schon eine Lösung – die Phoronix Test Suite.

Mit ihr lässt sich zwar nicht der Leistungsunterschied zwischen Programm X und Y messen, jedoch bietet sie umfangreiche Tests an, um Komponenten eines Computers auf Herz und Nieren zu prüfen. Wie performant ist mein Rechner gegenüber Modell xy eigentlich? Mit der Phoronix Test Suite kann man einer Antwort auf diese Frage näher kommen.

Mich interessierte für mein Multi-Boot System hingegen wie sich die drei unterschiedlichen Distributionen Ubuntu 11.04 (64bit), Debian Testing (32 bit) und Arch Linux (64bit) auf dem gleichen Rechner schlagen. Würde es große Unterschiede zwischen den beiden 64 bit Systemen von Arch Linux und Ubuntu 11.04 geben und wie würde Debian Testing als 32 bit Betriebssystem abschneiden?

Ich habe mich schließlich für die linux-system Test Suite entschieden, welche mit vielen Untertests nach eigener Aussage die Gesamtperformance eines Linux Systems im Vergleich zu anderen darstellen kann.

Die Phoronix-Test-Suite ließ sich wie gewohnt installieren. In allen drei Distributionen gab es schon vorgefertigte Pakete. Die Tests sind bei jeder Distribution die gleichen und mussten nur ein einziges Mal heruntergeladen werden. Danach genügte ein phoronix-test-suite make-download-cache, wodurch die Tests im versteckten Ordner ~/.phoronix-test-suite/download-cache abgelegt wurden und nur noch zwischen den Systemen kopiert werden mussten.

Die Test-Suite selbst wird mit dem Kommando

phoronix-test-suite benchmark linux-system

ausgeführt. Möchte man nur die Tests herunterladen genügt install anstelle von benchmark, zum Ausführen ist es der Befehl run.

Insgesamt sollte man für eine so umfangreiche Test-Suite genug Zeit einplanen, da die Pakete teilweise auf dem Zielsystem noch kompiliert werden und zusätzliche Pakete über die Paketverwaltung installiert werden. Bei Debian und Ubuntu verlief dieser Prozess meistens reibungslos, bei Arch Linux musste ich öfter manuell nachhelfen. Selbst dann gelang es mir nicht alle Tests erfolgreich auszuführen. Da es aber genug vergleichbare Tests auch mit Arch schafften durchzulaufen, sieht das Ergebnis am Ende meiner Meinung nach eindeutig aus.

Das Ergebnis habe ich der Einfachheit halber gleich auf openbenchmarking.org veröffentlicht. Dort finden sich auch Details zu den getesteten Komponenten des Rechners. Alle Distributionen waren zum Zeitpunkt des Tests auf dem aktuellen Stand. Kernel 2.6.38 und das ext4 Dateisystem kamen standardmäßig bei allen zum Einsatz. Als Desktopumgebung setzte ich bei Debian Testing auf Gnome 2.30, bei Ubuntu 11.04 auf Unity und mit Arch Linux auf Gnome 3.

Das Ergebnis

Phoronix-Test-Suite: pts/linux-system Intel Core 2 Duo e7400, Ubuntu 11.04, Debian Testing (wheezy), Arch Linux

Nicht ganz überraschend ist mein 32 bit Debian Testing System bei dieser Test-Suite abgeschlagen Letzter geworden. Lediglich bei Minion, dem Threaded I/O Tester und POV-Ray liegt wheezy vorne. Die restlichen Tests zeigen deutlich, dass zwischen den beiden 64 bit Distributionen Ubuntu 11.04 und Arch Linux kein großer Unterschied besteht. Wenn überhaupt liegt Ubuntu bei Encoding und rechenintensiven Tests, bei denen ein 64 bit System seine Vorteile deutlich ausspielen kann, knapp vorne.

Die größten Ausreißer gab es bei dem Postmark Test, wo wheezy komplett aus der Reihe fällt und dem Apache Benchmark, wo Arch Linux deutlich hinterher hinkt. Die Werte weichen zu deutlich von den anderen ab, weshalb ich denke, dass hier ein Messfehler vorliegt.

Die ganzen Tests haben nachträglich noch einmal bestätigt, dass es absolut sinnvoll ist für Audio-, Video- und Bildbearbeitung ein 64 bit Betriebssystem einzusetzen. Ob es nun Arch Linux oder Ubuntu 11.04 ist, scheint weniger wichtig zu sein. Letzteres war scheinbar keine schlechte Wahl.

Die Phoronix Test-Suite bietet aber auch Kritikpunkte. So sinnvoll ich es halte, dass es sich immer um die gleichen Tests handelt, es wird dadurch aber nicht einfacher herauszufinden, ob es eventuell distributionsspezifische Vorteile bei einzelnen Programmen gibt.

Des weiteren ist eine solche Test-Suite immer auch ein Extremtest und spiegelt nicht den alltäglichen Gebrauch eines Computers wider. Sollte ich aber irgendwann den ganzen Tag nichts anderes tun als 1GB große Dateien mit GnuPG zu verschlüsseln, mache ich das am besten mit Ubuntu 11.04 (64bit). Komprimiere ich Dateien mit LZMA sollte es wohl besser Arch Linux(64bit) sein.

Wenn ihr euch den Spaß machen möchtet und genau diese Testumgebung auf eurem Rechner ausprobieren wollt, können die Resultate direkt mit folgendem Befehl verglichen werden:

phoronix-test-suite benchmark 1105157-IV-20110514D92

Zum Schluss habe ich mir ein anderes Resultat vorgenommen, welches die Tests Unigine Heaven und Openarena schon ausgeführt hatte. Im Prinzip ging es um den Vergleich Radeon 4870 gegen meine Nvidia 9600 GT. 32 bit versus 64 bit spielte hierbei keine Rolle. Die Auflösung betrug 1680×1050 Pixel. Alle Distributionen konnten auf die aktuellen Nvidia Treiber zurückgreifen.

Unigine Heaven Test Nvidia 9600 GT Ubuntu 11.04, Debian Testing (wheezy), Arch Linux

Bedauerlicherweise erreichte ich mit keinem der Distributionen die vorgegebenen Framewerte. Am schlechtesten schnitt dabei Arch Linux ab. Ich versuchte es deshalb mit OpenArena erneut, wo Ubuntu 11.04 (+compiz) 346,23 fps erzielen konnte.

Debian Testing (+compiz) erreichte 330 fps und Arch Linux (Gnome 3) 329,57 fps. Die Unterschiede waren also nur marginal.

Ergebnis OpenArena Wheezy
Ergebnis OpenArena Arch Linux

Interessant wurde es noch einmal als ich den OpenArena Test mit wheezy ohne compiz wiederholte und dabei 376,27 fps erreichte.

Ergebnis OpenArena Wheezy ohne compiz

Das Ergebnis lässt den Schluss zu, dass 32 bit oder 64 bit bei den Tests keine große Rolle spielte. Wichtiger sind verwendete Grafiktreiber, die Grafikkarte selbst und ob ein Compositing Fenstermanager wie compiz aktiviert war oder nicht. Für Spieler lässt das nur den Schluss zu, dass weniger Compiz beim Spielen mehr ist.

Alles in allem zeigen die Phoronix Tests, dass die allgemeine Grundperformance bei vergleichbarer Architektur sehr ähnlich ist. Optimierungen und Verbesserungen einzelner Anwendungen konnte die Test-Suite aber nicht messen. Ob ein System mit speicherhungrigen Programmen überladen war oder dezent nur das Notwendige installiert war, ließ sich mit den Tests nicht feststellen.

Ubuntu 11.04: Speicherverbrauch und Compiz

Einige kennen sicherlich die Wettervorhersage, wo die Moderatorin verkündet: „Es ist heute 14 Grad, gefühlt 9 Grad.“ Das Bemerkenswerte an dieser Aussage ist, wie Volker Pispers mal zu sagen pflegte, dass die Meteorologen scheinbar wissen, wie kalt es einem selbst ist.

Ähnlich verhält es sich mit dem Speicherverbrauch und der gefühlten Geschwindigkeit bei Ubuntu 11.04 und meiner neuen Debian Testing-Installation. Direkt nach dem Start in Ubuntus neuen Unity Desktop zeigt die Systemüberwachung knapp 300 MB Speicherauslastung und mit aktiviertem Ubuntu One sind schon fast 340 MB erreicht. Meine Debian Wheezy-Installation auf dem gleichen Rechner begnügt sich erst einmal mit knapp 200 MB.

Genauso exakt wie die Temperaturen der Wettervorhersage lassen sich zwei verschiedene Linuxdistributionen vergleichen. Gefühlt starten und verhalten sich Icedove und Iceweasel bei mir schneller als ihre Ebenbilder Thunderbird und Firefox unter Ubuntu. Nautilus ist reaktionsfreudiger und auch meine Compiz Konfiguration mit Debian ist gefühlt um einiges effizienter als das ubuntische Derivat.

Doch es gibt auch Fakten, die meine Gefühle unterstützen:

Ubuntu benutzt zusätzliche Dienste, die ich bei Debian in dieser Form nicht brauchen werde: unity-applications-daemon, unity-window-decorator, unity-panel-service, und ganz dominant compiz an erster Stelle. Nicht zu vernachlässigen sind natürlich auch Dienste wie Zeitgeist und Ubuntu One, die permanent aktiv sein müssen um Veränderungen am System feststellen zu können.

Manchmal ist es so wie mit dem Apfel und Birnen Vergleich. Trotzdem wundert man sich, woher dieser Unterschied kommt, wenn es um die Reaktionsfähigkeit von Programmen geht. Wieso „verbraucht“ compiz bei meiner Ubuntu 11.04 Installtion (32 bit) 74 MB, während Debian Testing sich mit 28 MB begnügt. Es sind die gleichen Pakete und die gleichen Effekte oder doch nicht?

Mich stört es nicht sonderlich bei 4 GB RAM, ob ein Programm 40 MB mehr RAM einnimmt als mit einer anderen Distribution. Interessant finde ich nur, dass Programme wie die Gnome-Systemüberwachung nicht mit absoluter Sicherheit verdeutlichen können, woran es nun genau liegt und in welcher Hinsicht ein Ubuntu-Paket gegenüber dem Debian-Paket verändert wurde, damit ein solcher Effekt eintritt.

Was aber all die Zahlen zumindest ein wenig klarer erscheinen lassen und um wieder auf das Gefühl zurückzukommen. Debian Testing fühlt sich für mich im Moment einfach schneller an.

Wenn ich genau darüber nachdenke, erscheint mir Ubuntus Unity-Desktop im Moment nur eine andere Standardkonfiguration für Compiz zu sein, angereichert mit einem Dock ähnlich dem des avant-window-navigators und einem MacOS X ähnlichen Panel.

Zumindest letzteres ist erst einmal ein Merkmal von Ubuntu, welches sich nicht ganz so einfach mit einer Standardinstallation von Debian realisieren lässt. Anders schaut es aber mit ein paar Compiz Funktionen aus.

In Ubuntu 11.04 lässt sich mit der Linux-Taste + s zwischen der normalen Ansicht und einem in vier Arbeitsbereiche geteilten Desktop wechseln. Das Plugin von Compiz, welches eine solche Ansicht ermöglicht, heißt „Expo“.

Mit dem CompizConfig Einstellungs-Manager genügt es in Debian deshalb einfach das Expo Plugin zu aktivieren und unter „Allgemeine Compiz Optionen“ die Desktop Größe anzupassen. Virtuelle horizontale Größe und vertikale virtuelle Größe haben jeweils den Wert 2. Aktiviert man dann noch die „Desktop Tafel“ hat man den gleichen Effekt wie unter Ubuntu 11.04.

Mit etwas Lust zur Konfiguration hat man in Debian also schnell ähnliche Effekte wie in Ubuntu. Der Vergleich von Speicherverbrauch zwischen Distributionen ist dennoch nicht ganz trivial. Oft ist es wie mit dem Wetter: Gefühlssache.