Datenturbo

Dieser dritte und letzte Teil des Linux-Server-Tuning-Tutorials nimmt die wohl häufigsten Quellen von Leistungsengpässen unter die Lupe: das Netz- und das Plattensubsystem. Wie in den ersten beiden Teilen gilt auch hier, dass die enorme Zahl von Optimierungsmöglichkeiten deren vollständige Aufzählung unmöglich macht. Auf Grund der schieren Menge beschränkt sich dieser Artikel auf die wichtigsten Parameter, die den größten Einfluss auf die Leistung haben.

Eine neue Herausforderung bringt die Tatsache mit sich, dass sich sowohl mit dem Platten- als auch mit dem Netzsubsystem die Mitspieler nicht mehr im eigentlichen Server, also der physischen Box befinden müssen. So ist es bei größeren Plattensubsystemen nicht unüblich, dass diese als separate Plattenserver über ein SAN (Storage Area Network) bereitstehen. Bei Netzen liegt es geradezu in der Natur der Materie, dass man das System verlässt. Diese Tatsache kann aber Tuning-Maßnahmen und Leistungsanalysen komplizieren. Genügt es beim Prozessorsubsystem, Benchmarks auf dem betreffenden Server laufen zu lassen, um Leistungswerte zu erhalten, weiß man beim Netzsubsystem nie, ob der Flaschenhals nun auf dem Server oder eher in den unendlichen Weiten des Netzes liegt. In diesem Sinne sei bei der folgenden Analyse von Netz und Festplatten stets daran gedacht, dass man sich in einem viel breiteren Kontext bewegt als in den ersten beiden Teilen.

Der erste Teil des Tutorials diskutierte das Für und Wider modularer Kernel. Deren großer Vorteil liegt klar in der Option, Treiber im Betrieb aktualisieren zu können ohne den Kernel neu übersetzen und starten zu müssen. Dies sollte man in jedem Fall ausnutzen. Oft aktualisieren Hardwarehersteller oder freie Entwickler die Linux-Module, sodass sich oft mehr Leistung beziehungsweise mehr Effizienz, bei den Subsystemen erzielen lässt.

Vor einer Neuinstallation sollte man in jedem Fall die Webseiten der Hardwarehersteller konsultieren, um nach der Installation gleich Treiber- oder Firmwareaktualisierungen durchführen zu können. Nicht selten ließ sich nach dem Einspielen eines effizienteren Moduls die Leistung eines Systems nochmals um mehrere Prozentpunkte verbessern - von allfälligen Bugfixes ganz zu schweigen.

Messungen am Netzwerksubsystem

In diesem Artikel beschränkt sich die Analyse des Netzsubsystems auf das weit verbreitete Ethernet, auch wenn beispielsweise mit ATM, Myrinet oder InfiniBand viele weitere Netzwerktechniken existieren. Eine Warnung noch vorab: Performance-Messungen am Netzsubsystem sind besonders komplex, da sich das Leistungsverhalten des Netzes der Analyse meist entzieht. Daher muss man sich einige vereinfachende Voraussetzungen vor Augen führen. Generell können moderne Server auch bei kleinen Paketgrößen ein Gigabit-Ethernet auslasten, das heißt, die Netzhardware bis zum physikalischen Maximum belasten (englisch Line Speed). Auf Grund der TCP/IP-Implementierung gilt: Je größer die IP-Pakete, desto effizienter die Kommunikation. Daher liegt bei der Analyse ein besonderes Augenmerk auf der durchschnittlichen Paketgröße. Diese sollte idealerweise exakt in einen Ethernet-Frame passen, also 1500 Bytes oder ein Vielfaches davon betragen.

Das Beispiel in Listing 1 zeigt, dass dieses System etwa 1,8 GByte Daten übertragen hat. Dividiert man diesen Wert durch die Anzahl übertragener Pakete, erhält man die durchschnittliche Paketgröße. Das Beispielsystem überträgt durchschnittlich 334 Bytes pro Paket, hier ließe sich also noch Effizienz gewinnen. Besteht die Möglichkeit, die Applikationen zu größeren Netzpaketen anzuhalten, sollte man dies in jedem Fall tun.

2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:02:55:7c:74:eb brd ff:ff:ff:ff:ff:ff

    RX: bytes    packets  errors  dropped overrun mcast
    805226883    4694101  0       0       0       0
    TX: bytes    packets  errors  dropped carrier collsns
    1969563517   5891341  0       0       0       0

Die Tücken von Plug-and-Play

Es mag beinahe anmaßend klingen, doch eine der einfachsten Optimierungsmaßnahmen bezieht sich auf das Auto-Sensing. Die meisten Netzwerkkarten und so mancher Switchport sind darauf eingestellt. Dies allein stellt noch kein Problem dar, jedoch einigen sich Netz-Interface und Switchport allzu oft nicht auf den größten, sondern auf den kleinsten gemeinsamen Nenner. Direkt nach einer Installation fällt dies nicht auf, da das System Netzpakete senden und empfangen kann. Erst unter Last fällt die dürftige Leistung auf. Abhilfe schafft eine kritische Prüfung der Interface-Einstellungen nach der Installation und, falls möglich, deren statisches Festlegen. Zur Analyse empfiehlt sich ethtool, das viele Informationen über die Konfiguration des jeweiligen Interface liefert. Man sollte also per ethtool ethX (wobei X für die Interface-Nummer steht) stets prüfen, mit welchen Parametern das Interface läuft. Ein Eintrag der gewünschten Geschwindigkeit in /etc/modules.conf oder /etc/modprobe.conf macht die Einstellungen permanent.

Einige TCP/IP-Optimierungen

Als die DARPA (Defense Advanced Research Projects Agency) die TCP/IP-Protokollfamilie entwickelte, lag der Fokus auf hohen Ausfalltoleranzen - schließlich wollte man gegen Totalausfälle einzelner Internetknoten im Kriegs- und Katastrophenfall gewappnet sein. Der TCP/IP-Stack in Linux setzt ebenfalls ein Hauptaugenmerk auf unzuverlässige Datenleitungen. Dies mag bei analogen Wählleitungen ins Internet zwar sinnvoll sein, ist aber bei Servern im Rechenzentrum eine überflüssige Sicherheitsvorkehrung. Paketverluste in modernen Gigabit-Ethernet-Netzen sind selten, sodass man guten Gewissens einige der Sicherheitsvorkehrungen deaktivieren kann, um mehr Leistung zu erzielen. Mit dem /proc-Dateisystem und der sysctl-Schnittstelle bietet Linux einen einfachen Weg, Änderungen am Netzsubsystem des Kernel vorzunehmen. Beim sysctl-Einsatz sei daran erinnert, dass jegliche Änderungen nur bis zu einem Neustart gelten. Abhilfe kann hier ein einfaches, beim Systemstart ausgeführtes Skript oder ein Eintrag in /etc/sysctl.conf schaffen.

procs ---------memory-------- -swap- -----io---- -system- ----cpu-----
r b   swpd free  buff   cache si  so    bi    bo   in  cs us sy id  wa
2 1      0 9004 47196 1141672  0   0     0   950  149  74 87 13  0   0
0 2      0 9672 47224 1140924  0   0    12 42392  189  65 88 10  0   1
0 2      0 9276 47224 1141308  0   0   448     0  144  28  0  0  0 100
0 2      0 9160 47224 1141424  0   0   448  1764  149  66  0  1  0  99
0 2      0 9272 47224 1141280  0   0   448    60  155  46  0  1  0  99
0 2      0 9180 47228 1141360  0   0  6208 10730  425 413  0  3  0  97
1 0      0 9200 47228 1141340  0   0 11200     6  631 737  0  6  0  94
1 0      0 9756 47228 1140784  0   0 12224  3632  684 763  0 11  0  89
0 2      0 9448 47228 1141092  0   0  5824 25328  403 373  0  3  0  97
0 2      0 9740 47228 1140832  0   0   640     0  159  31  0  0  0 100

avg-cpu:  %user %nice %sys %idle
          10.95  0.00 1.00 88.06

Device:   rrqm/s  wrqm/s  r/s   w/s  rsec/s   wsec/s   rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
/dev/sdb1 438.81 3165.67 6.97 30.35 3566.17 25576.12 1783.08 12788.06   781.01   101.69 2728.00 268.00 100.00

In der gedruckten Ausgabe der iX erfahren sie darüber hinaus, wo sich im TCP/IP-Stack noch weitere Leistungsreserven aktivieren lassen und wie man dem Plattensubsystem auf die Sprünge helfen kann.

Durch einen Versehen bei der Heftproduktion fehlen in der gedruckten Fassung leider die im Text referenzierten Listings mit den Beispielausgaben.

Literatur

[1] Wilhelm Dolle, Christoph Wegener; Kernel-Interna; Geordnetes Warten; I/O-Scheduling in Linux 2.6; iX 7/2005, S. 110

[2] Eduardo Ciliendo; Linux Tuning I; Filigranarbeit; Performance-Tuning für Linux-Server; iX 1/2006, S. 130

Teil I: Einführung, generelle Optimierungsmaßnahmen

Teil II: Schnelle Systemkomponenten, CPUs und Speicher (avr)