Herzoperation

Die erste Aufgabe beim Performance-Tuning besteht darin, die Engpässe im System auszumachen. Die meisten davon finden sich im I/O-Subsystem, beim Memory-Management oder dem Scheduler. Zum Aufspüren dieser Flaschenhälse verfügt Linux über eine gut bestückte Werkzeugkiste. Einige Tools darin eignen sich eher, um den Gesamtzustand des Systems zu beurteilen. Andere sammeln sehr spezifische Informationen über einzelne Komponenten. Dieser Beitrag stellt Vertreter beider Klassen vor.

Viele der aufgeführten Tools richten praktisch alle gängigen Distributionen bereits standardmäßig ein. Einige der Werkzeuge zählen zum Umfang des Pakets sysstat, das Sie meist von Hand beziehungsweise über den Paketmanager Ihrer Distribution nachrüsten müssen. Zu guter Letzt erweisen sich noch die von Intel entwickelten Tools Latencytop und Powertop bei der Optimierung als hilfreich.

Überblick mit Vmstat

Ein guter Ausgangspunkt für eine Performanceanalyse ist ein Gesamtüberblick über die Befindlichkeit des Systems, wie ihn vmstat liefert. Das Beispiel in Listing 1 stammt aus der Messung eines CPU-intensiven Java-Workloads:

# vmstat
procs ———--memory———- —swap-- —--io—- —system-- —-cpu—-
 r  b   swpd   free   buff  cache   si   so    bi    bo   in     cs us sy id wa
 7  0  34328 757464   2712  26416    0    0     0     0   12 616773 34 28 37  0

Die ersten beiden Spalten zeigen, wie viele Prozesse das System ausführen kann, sobald ihnen die CPU zur Verfügung steht (r), und wie viele derzeit blockiert (b) sind. In diesem Fall warten sieben Prozesse in der Run-Queue auf eine Zeitscheibe der CPU, es liegen keine blockierten Prozesse vor. Übersteigt die Anzahl der Prozesse in der Warteschlange vor der CPU (Run-Queue) dauerhaft die Anzahl der Prozessoren respektive CPU-Cores im System, dann deutet das auf eine Überlastung der CPU-Ressourcen hin.

Die Prozesse, die die Spalte b zusammenzählt, schlafen, während sie auf einen Event warten. Meistens handelt es sich dabei um einen noch nicht abgeschlossenen Ein/Ausgabe-Vorgang. Eine hohe Anzahl blockierter Prozesse weist auf ein Performance-Problem hin: In dem Fall sollten Sie untersuchen, worauf genau die Prozesse warten müssen. Im Allgemeinen sollten die Werte in den Spalten r und b möglichst niedrig ausfallen.

Die nächsten vier Spalten unter der Überschrift memory vermitteln einen Eindruck von der Speicherverwaltung. Im Einzelnen geben sie an, wie viel Swap-Space das System nutzt, wie viel RAM derzeit frei ist und wie viel Arbeitsspeicher Buffer und Cache verwenden. Von besonderem Interesse sind dabei die beiden Spalten si und so: Sie geben an, wie viel Memory das System auf die Platte auslagert (so, "Swap out") beziehungsweise wieder einliest (si, "Swap in"). Enthalten die Spalten über einen längeren Zeitraum höhere Werte als Null, so deutet das entweder auf zu knappe RAM-Bestückung des Rechners oder übermäßige Speicheranforderungen der Applikationen hin. In jedem Fall bremst jedes Swappen das System.

Die nächsten beiden Spalten bi und bo zeigen die Anzahl von empfangenen und gesendeten Datenblöcken für die Blockgeräten, was einen Indikator für die Plattenaktivität darstellt. Diese Zahl sollte zur Arbeitslast passen; erweisen sich die Disks länger als viel beschäftigt, handelt es sich um einen I/O-lastigen Workload.

Die Spalten in und cs unter der Überschrift system verraten etwas über die Anzahl der Interrupts und Context-Switches. Im Fall einer sehr hohen Interrupt-Rate empfiehlt es sich, die Quelle dieser Unterbrechungen zu identifizieren. Dabei hilft der Befehl sar -I XALL. Die Menge der Context-Switches sollte im Verhältnis zur Anzahl laufender Prozesse nicht zu hoch ausfallen, weil jeder Context-Switch durch das Zurückschreiben von Cache-Inhalten einen merklichen Overhead erzeugt. Zu viele Kontextwechsel können ein Anzeichen für einen Konflikt um Locks sein ("Lock Contention"): Dann versuchen verschiedene Prozesse gleichzeitig auf eine allen zugängliche Ressource zuzugreifen.

Die nächsten vier Spalten (us, sy. id und wa) dienen als Indikatoren dafür, wie viel Zeit die CPU jeweils für Applikationen im Userland, den Kernel, im Leerlauf und mit Warten auf Ein- und Ausgaben zugebracht hat. Wünschenswert ist hier ein hoher Zeitanteil für Anwendungen (us) und damit für Arbeit, die Ihnen direkt zugutekommt. Beobachten Sie hier dagegen einen hohen Anteil an Systemzeit und gleichzeitig sehr viele Kontextwechsel, weist das deutlich auf ein mögliches Locking-Problem hin. Wie man in diesem Fall einer solchen Lock-Contention weiter auf den Grund geht, erläutert dieser Beitrag weiter unten im Abschnitt "Locking-Probleme".

Ein hoher Anteil Idle-Zeit sollte idealerweise ebenfalls nicht das Ziel sein. Summiert sich dazu Leerlaufzeit in der Spalte wa, dann weist das auf einen I/O-Bottleneck hin: Der Rechner muss dann in der Regel auf die Festplatten warten.

Platten-Check

Ein einfaches Mittel, um zu überprüfen, ob Sie die Festplatten richtig konfiguriert haben und diese störungsfrei laufen, bietet hdparm. Das Kommando gibt einmal die Lesegeschwindigkeit beim Zugriff über den Buffer-Cache und zum anderen ohne Pufferung aus (Listing 2). Der zweite Wert sollte nahe an der Maximalgeschwindigkeit der Platte liegen. Fällt er zu niedrig aus, sollten Sie überprüfen, ob die Konfiguration möglicherweise nicht dem Optimum entspricht – so könnten Sie beispielsweise im BIOS einen Kompatibilitätsmodus eingestellt haben.

Einen guten Überblick über alle hardwarenahen Parameter der Platte vermittelt der Aufruf von hdparm -I /dev/Device beziehungsweise für SCSI-Platten analog sdparm. Performance-relevante Parameter wie DMA Setup Auto-Activate optimization sollten korrekt eingestellt sein.

# hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 11724 MB in 2.00 seconds = 5870.80 MB/sec
Timing buffered disk reads: 184 MB in 3.02 seconds = 60.88 MB/sec