Workshop: Performance-Analyse mit collectd, serverstats, iostat und sar

Das Wichtigste an der Messung von Performance-Werten ist, dass Sie nicht sofort anfangen zu messen. Als Anregung finden Sie nachfolgend zuerst einmal fünf Regeln, die bei einer Performance-Analyse wichtig sind:

1. Dokumentieren Sie Ihre Beobachtungen und Ergebnisse. Vermutungen und Rückschlüsse müssen Sie entsprechend Ihren Daten zuordnen.

2. Stellen Sie eine sogenannte Baseline Performance Ihrer Systeme auf. Diese Baseline ist ein definierter Ausgangszustand, auf den hin Sie Messungen relativieren.

3. Messen Sie bei der Analyse den Zustand des Systems vor einer etwaigen Änderung. Alle Daten, die Sie zu einem definierten Zustand des Systems sammeln, helfen weiter.

4. Finden Sie die Engpässe in Ihrem System. Welche Ressourcen limitieren die Performance?

5. Treffen Sie realistische Abschätzungen, welche Maßnahmen die Performance verbessern, und beschränken Sie sich bei der Optimierung auf diese Teile.

Iostat

Daten zu Ein- und Ausgabe-Operationen sind insofern wichtig, als im Falle von Engpässen das I/O-System die gesamte System-Performance beeinflusst. Als Beispiel dient hier der Parameter "iowait", jene Zeit, in der die CPU auf die Abarbeitung von I/O-Requests wartet. Große I/O-Wartezeiten müssen nicht immer, können aber eine Ursache für hohe Load am System sein.

Iostat ist Teil des Packages sysstat, das in den Ubuntu Repositories als "System Performance tools for Linux" auftritt. Weitere Programme aus diesem Package sind sar, das im weiteren Verlauf vorgestellt wird, pidstat, mpstat, nfsiostat und cifsiostat. Die sysstat-Programme sind durchwegs Front-Ends zum proc-Dateisystem des Linux-Kernels. Sie können daher auch nicht mehr Statistiken bereitstellen, als der Kernel für /proc anbietet.

Um Geräte-Statistiken abzufragen, bietet iostat die Option -d. Mit dem Schalter-c liefert das Tool den CPU Utilization Report. Beachten Sie, dass der erste Output standardmäßig die Werte seit dem Systemstart beinhaltet. Alle weiteren Reports beziehen sich auf das Intervall zwischen den einzelnen Ausgaben. Wer möchte, überspringt den ersten Report mit der Option -y und erhält dadurch nur die aktuellen Werte.

Performance-Kennzahlen

Der erweiterte Output über -x gibt einen Parameter aus, der für viele Benutzer auf den ersten Blick ein Faktor für die Auslastung des Devices ist: %util (Listing 1).

Ein Blick in die Manpage korrigiert jedoch den häufigen Irrglauben, dass %util die eigentliche Device-Auslastung angibt: %util ist der Anteil an CPU-Zeit, in dem I/O-Requests an das Device abgesetzt wurden. Für einzelne traditionelle Festplatten mag es zwar stimmen, dass ein hoher %util-Wert ein Indikator für eine gute Auslastung des Devices ist. RAID Devices oder SSDs verarbeiten aber mehrere Requests parallel, daher relativiert sich die investierte CPU-Zeit für das Device.

$ iostat -y -x -d 3 5
Linux 3.13.0-37-generic (X220)      2014-10-17      _x86_64_      (4 CPU)
Device: rrqm/s    wrqm/s    r/s      w/s             rkB/s    wkB/s       avgrq-sz    avgqu-sz    await    r_await    w_await    svctm    %util
sda        0,00       2,00         0,00   15520,67   0,00     62090,67  8,00           0,48           0,03      0,00          0,03          0,03       48,00

Bessere Indikatoren für die richtige I/O-Auslastung sind %iowait im CPU-Report sowie avgqu-sz und await im Disk-Report. %iowait ist der Anteil an CPU-Idle-Zeit, während dem auf dem System noch I/O-Requests ausstanden. Ein weiterer Fallstrick wartet jedoch auch hier: %iowait ist eine spezielle Ausprägung von Idle-Zeit und somit ein Subparameter der eigentlichen CPU-Idle-Zeit. Laufen auf einem CPU-Kern ein Task, der %iowait steigen lässt, und zugleich ein CPU-rechenintensiver Task, sinkt automatisch %iowait. Dieser Umstand ergibt sich daraus, dass der zweite Task CPU-Zeit verbraucht und somit keine Idle-Zeit mehr vorhanden ist.

Ein simples Experiment verdeutlicht das (Listing 2). Die zugehörigen Ausgaben von top und iostat bringen die Idle-Zeiten ans Licht (Listing 3). Läuft der rechenintensive Task zugleich mit dem I/O-Task, ist %iowait gleich Null, %util aber gestiegen (Listing 4). Wie zuvor angesprochen, sind neben den CPU-affinen Idle-Zeiten die dem Device näheren Werte avgqu-sz und await signifikant.

# taskset 1 fio --rw=randwrite --name=test --filename=test.fio --size=100M --direct=1 --bs=4k --numjobs=1 --iodepth=64 --group_reporting --runtime=120 --time_based --refill_buffers
# taskset 1 sh -c "while true; do true; done"

%Cpu0 :    77,7 us,    22,3 sy,    0,0 ni,      0,0 id,    0,0 wa,    0,0 hi,    0,0 si,    0,0 st
%Cpu1 :      1,4 us,      0,7 sy,    0,0 ni,    98,0 id,    0,0 wa,    0,0 hi,    0,0 si,    0,0 st
%Cpu2 :      7,3 us,      1,6 sy,    0,0 ni,    89,9 id,    0,0 wa,    0,0 hi,    1,2 si,    0,0 st
%Cpu3 :      4,7 us,      1,0 sy,    0,0 ni,    94,2 id,    0,0 wa,    0,0 hi,    0,0 si,    0,0 st

avg-cpu:      %user      %nice      %system      %iowait      %steal      %idle
                     20,50       0,00         7,30             0,00            0,00          72,20
Device:    rrqm/s    wrqm/s    r/s     w/s             rkB/s    wkB/s          avgrq-sz    avgqu-sz    await    r_await    w_await    svctm    %util
sda           0,00       2,67         0,00  32549,67   0,00      130237,33  8,00           0,78           0,02      0,00          0,02          0,02       78,40

Iostat ist ein Werkzeug, das Statistiken auf Blocklayer-Ebene bereitstellt. Ein häufig angetroffener Begriff in diesem Zusammenhang sind Requests. Das sind jene Strukturen, mit denen der I/O-Scheduler von Linux arbeitet. Er übergibt diese an die Dispatch Queue des Device-Treibers, der den letzten Schritt in der Linux-I/O-Kette darstellt.

Der Wert avgqu-sz kennzeichnet die durchschnittliche Länge der Queue, die dem Device übergeben wurde. Er errechnet sich aus time_in_queue und dem iostat-Intervall. time_in_queue ist jene Zeit, in der Requests auf das Device warten mussten. Wenn mehrere in_flight-Requests warten müssen, erhöht sich time_in_queue um das Produkt von time_in_queue mal der Anzahl von in_flight [1]. Schlussendlich lässt sich avgqu-sz daraus berechnen [2].

(delta[time_in_queue] / interval) / 1000.0

Ein einfaches Beispiel mit fünf in_flight Requests in 20ms bei einem iostat-Intervall von fünf Sekunden würde als avgqu-sz 0,02 ergeben. Für ein Device gilt daher, je größer avgqu-sz bei gleichbleibender await-Zeit ist, umso mehr Requests konnte es verarbeiten.

Await wiederum ist die durchschnittliche Wartezeit, die für einen I/O-Request verbraucht wurde:

delta[read_ticks + write_ticks] / delta[read_IOs + write_IOs]

Die Produktregel für mehrere in_flight-Requests, die wir zuvor kennenlernten, gilt auch für die hier verwendeten ticks. Bereits aus der Herleitung der beiden Parameter lässt sich erkennen, dass sie sich als Indikatoren für die Device-Auslastung eignen. Große await-Zeiten bei kleinen avgqu-sz sind ein Kennzeichen dafür, dass auf die Abarbeitung der Requests durch das Device gewartet wird.