Abbildung 1: Von links nach rechts zeigt das Tool Ksar den I/O-Durchsatz eines wenig beschäftigten Mailservers, der Postfächer abklappert und Spam-Checks durchführt, eines mächtigen Fileservers für 100 Mitarbeiter, der nachts sein Backup erledigt und ab 8 Uhr die Mitarbeiter versorgt, sowie eines Desktop-Rechners.

Die Sysstat-Tools um Sar, Iostat, Mpstat und Pidstat erfassen Systemparameter und berechnen Statistiken – seit Version 8 erstmals auch die von einem einzelnen Prozess verursachte I/O-Last.

Jeder Admin kennt das Szenario: Der Server schwächelt oder versagt den Dienst. Bleibt die schnelle Suche nach Fehlern in Logfiles, unter »/proc« oder mit Tools wie Vmstat oder Top erfolglos, dann ist Sysstat gefragt. Das Statistik-Werkzeug sammelt zwar die Systeminformationen ebenfalls aus diesem Verzeichnis, speichert sie aber für einen frei definierbaren Zeitraum und stellt sie für Auswertungen über Durchschnittswerte, Grafiken oder die Abfrage einzelner Systemparameter zu einen bestimmten Zeitpunkten wieder zur Verfügung.

Dabei bietet es umfangreiche Details, aber am meisten werden sich Unix-Administratoren über die Optionen von Pidstat freuen. Da kann der Admin endlich wie auf anderen großen Unixen die I/O-Last pro Prozess abfragen und überwachen. Weil dafür eine spezielle Kerneloption notwendig ist, können das alte Distributionen nicht. Erst Ubuntu Hardy glänzt damit, bei Open Suse braucht es Version 11 oder wie sonst überall einen angepassten Kernel, damit die vom Entwicklerteam um Sebastien Godard gerade veröffentlichte Sysstat-Version 8 mit allen Optionen läuft.

Viele Fähigkeiten

Iostat, Pidstat, Sar und Konsorten geben auf unterschiedliche Weise Auskunft über eine ganze Reihe von Statistiken, die das System gesammelt hat:

• Input/Output- und Transferraten: global, nach Gerät,
  Partition, NFS-Laufwerk, Prozess-ID oder gleichlautenden
  Prozessnamen
• CPU-Nutzung: global, pro CPU oder nach Prozess
• Virtueller und realer Arbeitsspeicher sowie die Nutzung der
  Swapdateien
• Paging, Speichernutzung und Pagefault-Anzahl: global, für
  einzelne Prozesse oder Prozessbäume, also einen Prozess und
  alle seine Kinder
• Geschwindigkeit, mit der das System neue Prozesse
  generiert
• Anzahl der Interrupts: global, pro CPU, Interrupt oder
  APIC-Quellen
• Netzwerk-Interfaces
• NFS-Server und -Clients
• Sockets
• Runqueue und die Systemload
• Interne Kerneltables
• Menge der Context Switches
• Aktivität auf den TTYs

Die Informationen, die die Tools liefern, sind in der Regel in die Kategorien Speicher, Netzwerk, Prozessor(en), CPU und I/O eingeteilt. Bei Pidstat gibt die Option »-d« zum Beispiel die I/O-Last aus, »-r« die Pagefaults und »-u« die CPU-Nutzung, »-w« die Task Switching Activity des Kernels. Sar und Iostat haben darüber hinaus Schalter eingebaut, um die Daten von Netzwerk-Filesystemen anzuzeigen, mit Sar kann der Admin auch die Nutzung der TTY-Konsolen überwachen.

Linux-Urgesteine mögen jetzt monieren, das meiste davon ginge ja schon mit Bordmitteln, jeder Administrator könne mit Awk die Load Average über einen beliebigen Zeitraum berechnen lassen. Dafür braucht er nur ein wenig Shell-Wissen und die Daten aus dem Proc-Dateisystem (Abbildung 2). Das ist sicherlich richtig, aber mit dem Allround-Tool Sar aus dem Sysstat-Paket [1] geht das deutlich einfacher: Ein »sar -q P0 120 2« zeigt Queue Length und Load Average übersichtlicher an. »P0« beschreibt dabei die zu überwachende CPU und wegen »120 2« macht Sar zwei Durchläufe, jeweils über zwei Minuten, und zeigt danach die Durchschnittswerte für eine, fünf und 15 Minuten an. Die Ausgabe zeigt ebenfalls Abbildung 2.

Abbildung 2: Im Vergleich zu Sar und Pidstat erscheint Awk vergleichsweise umständlich und eingeschränkt.

Ein wahrer Allrounder

Damit nicht genug: Treten mysteriöse Hardware-Effekte auf, nimmt der Admin mit »sar -I Interrupt« einzelne Interrupts unter die Lupe. Und wenn er über die CPU-Auslastung, zum Beispiel über »sar -u«, festgestellt hat, dass der Server am oberen Ende seiner Leistungsfähigkeit angelangt ist, dann muss dies sicherlich noch nicht heißen, dass es Zeit für eine neue Maschine ist. Vielleicht zieht er erst die Langzeitbetrachtung heran, die sowohl an der Konsole als auch mit grafischen Tools möglich ist.

Hier bietet sich vor allem Ksar [2] an. Es bereitet die gesammelten Information in Diagrammen auf, bietet einen schnellen Überblick und kann mehrere Server via SSH-Befehl gleichzeitig darstellen (Abbildung 1). Das Java-Tool führt zum Beispiel »sar -A« auf einem entfernten Server aus und bekommt dabei die kompletten Sar-Daten zur Ansicht übermittelt und stellt sie bequem per Maus klickbar in einem Baumdiagramm dar.

Besonders schön ist, dass die Unterfenster synchronisiert sind. Ein Klick auf einen Unterpunkt im Baumdiagramm aktualisiert die Grafiken automatisch für alle angezeigten Hosts – für den Admin ideal, um mehrere Systeme zu vergleichen.

Prozessen auf der Spur

Häufig sind Bugs oder Loops in ausgeführten Programmen die Ursache, wenn ein Server in die Knie geht. Früher konnte der Linux-Admin das nur durch zeitaufwändige Betrachtungen mit Top, Strace und anderen Debugging-Tools erkennen und musste dabei am Bildschirm bleiben. Heute schafft ein in Sysstat enthaltenes Tool Abhilfe: Pidstat erzeugt Report-Statistiken für einzelne Linux-Tasks. Es lässt sich einsetzen, um Prozesse über einen längeren Zeitraum zu beobachten und abschließend einen Durchschnittswert zu berechnen.

Auf der Webseite [1] berichten die Entwickler von Sysstat, wie sie mit Pidstat einem Speicherleck in den Sysstat-Tools auf die Schliche kommen konnten. Betrachtet der Admin zum Beispiel mit »pidstat -u 20 2 -C Prozessname« einen einzelnen Prozess, dann erhält er für ihn die in zwei Abfragen innerhalb von 40 Sekunden ermittelte Durchschnittslast (siehe Abbildung 2).

Rein und raus

Wer einen Kernel ab 2.6.20 hat, in dem die Option »CONFIG_TASK_IO_ACCOUNTING« einkompiliert ist, kann mit Pidstat auch die I/O-Last einzelner Prozesse oder ganzer Gruppen überwachen. Auf solchen Systemen ergibt ein »pidstat -d 2 3« eine Ausgabe wie sie Abbildung 3 zeigt. Pidstat listet die Prozesse auf, die I/O verursachen, und gibt sogar die Art (Lesen oder Schreiben) und die Datendurchsätze (in KByte/s) aus.

Abbildung 3: Erstmals können Linux-Admins jetzt mit Pidstat die I/O-Last einzelner Prozesse überwachen.

Damit das Ganze funktioniert, braucht es neben einem aktuellen Kernel noch die Pakete von der Sysstat-Webseite und passende Einträge in der Cron-Konfiguration. Listing 1 zeigt die Datei »/etc/cron.d/sysstat«, wie sie auf Ubuntu vorliegt. Im einfachsten Fall reichen aber auch diese beiden Zeilen in »/etc/crontab«:

*/10 * * * * root /usr/lib/sa/sa1 1 1
53 23 * * * root /usr/lib/sa/sa2 -A

Der erste Eintrag startet den Sadc (System Activity Data Collector), den Serverdaemon, der jede Sekunde Daten sammelt und unterhalb des Verzeichnisses »/var/log/sa« ablegt. Das Format der Logdateien ist »saXX« wobei XX für das Datum steht. Die zweite Zeile mit »sar -A« sorgt für die Rotation der Logdateien.

01 # Global variables:
02 #
03 #  our configuration file
04 DEFAULT=/etc/default/sysstat
05 #  default setting, overriden in the above file
06 ENABLED=false
07 SA1_OPTIONS=""
08 # Activity reports every 10 minutes everyday
09 5-55/10 * * * * root [ -x /usr/lib/sysstat/sa1 ] && { [ -r "$DEFAULT" ] && . "$DEFAULT" ;
10 [ "$ENABLED" = "true" ] && exec /usr/lib/sysstat/sa1 $SA1_OPTIONS 1 1 ; }
11 # Additional run at 23:59 to rotate the statistics file
12 59 23 * * * root [ -x /usr/lib/sysstat/sa1 ] && { [ -r "$DEFAULT" ] && . "$DEFAULT" ; [
13 "$ENABLED" = "true" ] && exec /usr/lib/sysstat/sa1 $SA1_OPTIONS 60 2 ; }

Iostat und Mpstat

Neben Sar und Pidstat enthält das Paket noch Iostat und Mpstat. Während Letzteres ausführlichst einen angegebenen Prozessor überwacht, ist Iostat bei Administratoren von File-, Datenbank und Mailservern sehr beliebt, weil sich damit live die I/O-Last des Systems messen lässt, aufgeschlüsselt nach Laufwerken, Platten, Partitionen und Filesystemen. Zum Beispiel beobachtet »iostat -m -n 10 2« einen NFS-Mountpoint und gibt die Datenmenge in MByte an (Listing 2). Das Gleiche – nur für eine einzelne Partition – übernimmt »iostat -m -x sda2 10 2« in Listing 3.

01 # iostat -m -n 10 2
02 Filesystem:  rMB_nor/s wMB_nor/s  rMB_dir/s  wMB_dir/s  rMB_svr/s  wMB_svr/s  rops/s  wops/s
03 server:/home      0,03      0,01       0,00       0,00       0,01       0,02    6,53      6,53
04 
05 Filesystem:  rMB_nor/s wMB_nor/s  rMB_dir/s  wMB_dir/s  rMB_svr/s  wMB_svr/s  rops/s  wops/s
06 server:/home      6,65      6,64       0,00       0,00       6,65       0,81  252,40  252,40
07 #

01 # iostat -m -x sda2 10 2
02 avg-cpu:   %user    %nice  %system %iowait  %steal  %idle
03             2,01     0,01     0,52    0,40    0,00  97,05
04 
05 Device:   rrqm/s   wrqm/s      r/s     w/s   rMB/s  wMB/s  avgrq-sz  avgqu-sz  await  svctm  %util
06 sda2        0,71     3,32     1,09    0,85    0,02   0,02     38,13      0,06  28,37   2,87   0,56
07 
08 avg-cpu:   %user    %nice  %system %iowait  %steal  %idle
09             6,14     0,00     0,81    0,33    0,00  92,71
10 
11 Device:   rrqm/s   wrqm/s     r/s      w/s   rMB/s  wMB/s  avgrq-sz  avgqu-sz  await  svctm  %util
12 sda2        0,00    12,80     0,00    7,40    0,00   0,08     21,95      0,03   4,27   1,14   0,84
13 #

Absolut notwendig

Die jüngste Version des Sysstat-Pakets bringt Neuerungen, die sich viele Admins erhofft haben, vor allem die I/O-Last pro Prozess. Linux hatte hier noch gehörigen Nachholbedarf. Nur schade, dass dies nicht so ohne Weiteres auf älteren Servern oder Enterprise-Versionen läuft. Ob die Distributionshersteller mit passenden Kerneln und Paketen reagieren werden, erscheint fraglich.

Wer einstweilen auf die detaillierte I/O-Darstellung verzichten kann, dem bietet vor allem die Kombination Sar und Ksar eine flexible und umfangreiche Oberfläche, in der er mehrere Server gleichzeitig überwacht. Auch ohne Monitoring-Systeme geben sich so wiederkehrende Engstellen zu erkennen – der Admin reagiert, bevor der Ernstfall eintritt.