Dass Grundlagenforschung wichtig ist, zeigt der unter anderem an den deutschen Wissenschaftler Prof. Theodor W. Hänsch verliehene Nobelpreis für Physik. Prof. Hänsch, der auf dem Gebiet der Grundlagenforschung arbeitet, hat eine Methode zur exakten Bestimmung der Frequenz von Laserstrahlung mit entwickelt. Einen Nobelpreis werden wir wohl nicht gewinnen – dennoch hat es auch was mit Grundlagenforschung zu tun. Jeder Admin sollte sich, nicht nur bei Engpässen, mit der Analyse seines Linux Servers auskennen, dabei hilft ihm die Sysstat [1] Werkzeugsammlung vor allem mit dem SAR – System Activity Reporter.
Dieser kann ohne das System zu belasten sehr effektiv Aufzeichnungen aus allen vier Bereichen der Performance Analyse machen, die der Admin zu einem späteren Zeitpunkt auswerten kann. Somit lassen sich sehr elegant Lastprofile erstellen. Falls notwendig kann der SAR auch Echtzeitaufzeichnungen machen, die den aktuellen Stand des Servers darstellen. Die Daten bekommt SAR, wie die meisten Tools (vmstat, top etc.), aus dem »/proc« Dateisystem.
Von Grundlagen…
Zur Ermittlung des Gesamtzustandes eines Systems gibt es vier Kategorien, die betrachtet werden müssen:
- Prozessor
- Speicher
- I/O
- Netzwerk
Um die Ausgaben von SAR zu verstehen, und auch korrekt interpretieren zu können, sind ein paar Basics unverzichtbar. In der “Run Queue” stehen die Prozesse, die auf Zuteilung eines Prozessors warten. Je mehr Prozesse warten, desto länger ist die Run Queue. Da ein Prozessor immer nur einen Prozess ausführen kann, Hyperthreading einmal ausgenommen, wird zwischen diesen in einem bestimmten Intervall gewechselt. Diesen Wechsel nennt man “Kontext Switch”. Um sicherzustellen, dass jeder Prozess eine faire Zuteilung der CPU erhält, unterbricht der Kernel periodisch den laufenden Prozess und weist einem anderen Prozess die CPU zu. Die Anzahl der periodischen Kontext Switche ist Abhängig von Architektur und Kernel Version. Die Anzahl ist einfach zu ermitteln, indem man sich die Angaben aus dem Proc Dateisystem holt: Listing 1
Listing 1: Kontext Switche ermitteln.
[root@baldur ~]# cat /proc/interrupts | grep timer; sleep 10; cat /proc/interrupts | grep timer
0: 7520081 XT-PIC timer
0: 7530091 XT-PIC timer
[root@baldur ~]#
Die Differenz (10010) entspricht der Anzahl Kontext Switche in zehn Sekunden, das bedeutet etwa 1001 in der Sekunde.
Die ist wichtig zu wissen, falls die tatsächlich ausgeführten Kontext Switche deutlich höher ausfallen.
…und Foschung
Das Sysstat Paket liegt den meisten Distributionen bei und kann einfach mittels »yum install sysstat« oder »apt-get install sysstat« installiert werden. Nach der Installation sollte man erstmal einen »cronjob« eintragen, der das System etwas beobachtet. Das Listing 2 zeigt wie ein solcher Eintrag aussehen könnte.
Listing 2: Cron Eintrag für die Systembeobachtung
*/10 * * * * root /usr/lib/sa/sa1 1 1
53 23 * * * root /usr/lib/sa/sa2 -A
Bei dem ersten Eintrag handelt es sich um Script, welches den “sadc – System activity data collector” mit dem Intervall von einer Sekunde einmal aufruft. Der zweite Eintrag sorgt dafür, dass ein Logrotate für die erstellten Protokolle durchgeführt wird. Von diesem Zeitpunkt an steht das System schon gut unter Beobachtung und dies ohne dasselbige zu belasten. Dies sollte auf jedem Linux System installiert sein, damit man erstens ein Gefühl dafür bekommt wie stark ein System ausgelastet ist und zweitens im Ernstfall einen Engpass sicher identifizieren kann.
CPU Engpässe identifizieren
Die wichtigsten Optionen um alle Aktivitäten der CPU zu identifizieren sind in Tabelle 1 zu finden. Falls Probleme auftreten ist die CPU auch die erste Anlaufstelle. Ein einfacher Aufruf von »sar -u 2 10« zeigt die prozentuale Auslastung der CPU. Hier kann man schon einen ersten Überblick bekommen, wo das Problem steckt (hoher %iowait- oder %user-Wert).
Tabelle 1:sar CPU Parameter
- -c Anzahl der Prozesse, die pro Sekunde erzeugt werden
- -I {irq|SUM|ALL|XALL} Anzal der Interrupts / Sekunde
- -P {cpu|ALL} CPU-spezifische Informationen bei Mehrprozessorsystemen
- -q Informationen zur Run Queue und des Load Average
- -u Angaben zur CPU Auslastung (default)
- -w Anzahl Kontext Switche
Speicher Engpässe identifizieren
Hier zeigt sich SAR genauso mächtig oder gar mächtiger als andere Performancetools. Es ist möglich den aktuellen Speicherverbrauch mit allen zugehörigen Parametern anzuzeigen. Im Vergleich zu anderen Tools setzt SAR die Angaben immer in Relation zur Zeit. Das versetzt den Admin in die Lage, Veränderungen im Speicherverbrauch über einen gewissen Zeitraum zu sehen, ohne die Differenz zwischen zwei Momentaufnahmen errechnen zu müssen. Tabelle 2 zeigt die Speicherrelevanten Optionen von SAR.
Tabelle 2:sar Speicher Parameter
- -B Übersicht der Pageingstatistik
- -W Anzahl Swap Pages In und Out
- -r Gesamttübersicht über die Speichernutzung
I/O Engpässe identifizieren
Vorweg leider eine eher traurige Nachricht: Es ist mit dem aktuellen Linux Kernel nicht möglich den I/O Verbrauch einem einzelnen Prozess zuzuordnen. Aber in diesem Artikel geht es ja auch nicht um Prozessmonitoring, sondern um die Identifizierung von Systemengpässen. Die möglichen Optionen sind in diesem Fall auch nicht so umfangreich, wie bei der CPU oder dem Speicher. Ein Aufruf von »sar -d 2 10« gibt einen Überblick über den I/O-Verbrauch. Hier muss man natürlich wissen, wie man die Angaben interpretiert und die Festplatte mit der größten Last identifiziert. Die Ausgabe in Listing 3 zeigt ein Beispiel:
Listing 3: I/O Last per Device
Durchschn.: DEV tps rd_sec/s wr_sec/s
Durchschn.: dev1-0 0,00 0,00 0,00
Durchschn.: dev1-1 0,00 0,00 0,00
Durchschn.: dev1-2 0,00 0,00 0,00
Durchschn.: dev1-3 0,00 0,00 0,00
Durchschn.: dev1-4 0,00 0,00 0,00
Durchschn.: dev1-5 0,00 0,00 0,00
Durchschn.: dev1-6 0,00 0,00 0,00
Durchschn.: dev1-7 0,00 0,00 0,00
Durchschn.: dev1-8 0,00 0,00 0,00
Durchschn.: dev1-9 0,00 0,00 0,00
Durchschn.: dev1-10 0,00 0,00 0,00
Durchschn.: dev1-11 0,00 0,00 0,00
Durchschn.: dev1-12 0,00 0,00 0,00
Durchschn.: dev1-13 0,00 0,00 0,00
Durchschn.: dev1-14 0,00 0,00 0,00
Durchschn.: dev1-15 0,00 0,00 0,00
Durchschn.: dev3-0 31,09 5,97 6001,99
Durchschn.: dev22-0 0,00 0,00 0,00
Durchschn.: dev9-0 0,00 0,00 0,00
Die Ausgabe zeigt die durchschnittliche Last der Geräteknoten. Die zweite Spalte zeigt das jeweilige Device mit Major und Minor Nummer. Hier ist also das Device mit der Major-Nummer 3 und der Minor-Nummer 0 das einzige das vom System genutzt wird. Wenn man nun den sprechenden Namen des Devices ermitteln möchte, hilft ein »ls -l /dev | egrep ’3,\W*0′«. Was uns folgende Ausgabe beschert »brw-r—– 1 root disk 3, 0 18. Jun 2006 hda«. Die Festplatte »hda« ist also die Gesuchte. Hier hilft SAR zu ermitteln, welche Festplatte am häufigsten beansprucht wird.
Ist das Netzwerk der Flaschenhals?
Wenn alle Bereiche gründlich untersucht wurden, aber die Anwendung immer noch träge ist, kann es eventuell am Netzwerk liegen. Aus eigener Erfahrung kann ich sagen, dass viele Software-Hersteller vorhandene Performanceprobleme schnell auf das Netzwerk abwälzen wollen. Um solchen Problemen auf die Spur zu kommen, ist SAR sicherlich ein guter Einstiegspunkt. Der erforderliche Aufruf »sar -n DEV 2 10« gibt einen Überblick (siehe Listing 4) über die Netzwerkstatistik.
Listing 4: Netzwerkstatistik
Durchschn.: IFACE rxpck/s txpck/s rxbyt/s txbyt/s rxcmp/s txcmp/s rxmcst/s
Durchschn.: lo 6,09 6,09 407,74 407,74 0,00 0,00 0,00
Durchschn.: eth0 0,00 0,00 0,00 0,00 0,00 0,00 0,00
Durchschn.: wlan0 0,95 2,10 97,25 187,12 0,00 0,00 0,00
Die erste Spalte zeigt die jeweilige Netzwerkschnittstelle an. Die zweite und dritte Spalte zeigen die empfangenen / gesendeten Pakete pro Sekunde an. Die vierte und fünfte Spalte das Gleiche in Bytes pro Sekunde. Hie kann man schon ein Gefühl dafür entwickeln wie stark das Netzwerk ausgelastet ist und ob die Netzwerkschnittstelle der Flaschenhals ist. Aber auch die Kabel können zu trägen Antwortzeiten einer Applikation beisteuern. Um die entsprechenden Fehlerstatistiken anzusehen gilt der obige Aufruf, nur anstelle von DEV nimmt man EDEV, also »sar -n EDEV 2 10«. Sollten hier signifikante Größen auftreten kann ein Wechsel des Patchkabels oder des Netzwerkkartentreibers schon helfen. Das letzte Schlüsselwort ”SOCK” (sar -n SOCK 2 10) zeigt die Statistik über Sockets an. Hier kann SAR helfen einen Überblick über die genutzten Sockets (UDP oder TCP) zu bekommen.
Alt und doch nützlich
SAR ist in der alten Unix-Welt groß geworden. Viele Admins nutzen dieses Tool um einen Überblick über ihre Systeme zu bekommen. Dieses sogenannte Baselining ist wichtig um ein Gefühl für die betreuten Systeme zu ermitteln. Erst aufgrund dieses Gefühls kann der Admin im Ernstfall den Fehler schnell identifizieren und beheben. Im Vergleich zu anderen Tools liegt die Stärke von SAR in der Möglichkeit die Daten zu sammeln und auch historisch auszuwerten.
[1] Sysstat [http://perso.wanadoo.fr/sebastien.godard/]
