Egal, um welchen Dienst es sich dreht, den Benutzern geht es immer zu langsam. Der Schwerpunkt des ADMIN-Magazins 05/2011 verrät, mit welchen Tools man ... (mehr)

I/O im Blick

Wer nach einem ersten Überblick seine Erkenntnisse über eine bestimmte Ressource vertiefen möchte, dem bieten sich viele spezialisierte Monitore und Benchmarks an. Eine der Schwachstellen, die dabei am häufigsten in den Blick gerät, sind die Festplatten.

Das liegt einfach daran, dass sich in den vergangenen Jahrzehnten die Rechenleistung der CPU sehr viel schneller entwickelt hat als die I/O-Leistung der Festplatten. Ein Blick in die Computergeschichte macht das klar: Der Urahn heutiger CPUs, Intels 8086, erblickte im Juni 1978 das Licht der Welt und brachte es anschließend, getaktet mit bescheidenen 4.77 MHz, auf gerade einmal 0,33 MIPS (Million Instructions Per Second). Eine heutige CPU, etwa Intels Quadcore-Prozessor Core i7 Extreme Edition 990x, kommt bei 3,46 GHz auf 59 000 MIPS.

Bei den Festplatten sieht die Lage aber ganz anders aus. Kurz nachdem der legendäre Stammvater der Intel-Prozessoren auf den Markt kam, konstruierte Seagate seine erste 5,25-Zoll-Festplatte, das Modell ST-506. Die aus heutiger Perspektive winzige 5-MByte-Platte kostete stolze 1500 Dollar und brachte es bei einer Umdrehungsgeschwindigkeit von 3600 RPM auf eine mittlere Lesegeschwindigkeit von 85 ms. Eine aktuelle Barracuda 7200.7 (ST-380011A) hat zwar ihre Kapazität auf vergleichsweise riesige 80 GByte vergrößert, rotiert aber nur doppelt so schnell und das Lesen dauert hier immer noch 8,5 ms im Schnitt.

Das heißt: Während die CPU ihre Rechenpower auf das 178.000-fache steigerte, stieg die Lesegeschwindigkeit der Platten nur um das Zehnfache. Der Grund liegt in den Gesetzen der Mechanik: Die Rotationsgeschwindigkeit der Platten ist nicht beliebig steigerbar, unter anderem weil dann die unvorstellbar hohe Positioniergenauigkeit der Köpfe nicht mehr zu gewährleisten wäre, die wiederum die Voraussetzung für hohe Spurdichten und damit Kapazitäten ist.

Die enorme Diskrepanz in der Leistungsentwicklung von CPU und I/O-Subsystem ist die häufigste Ursache für Performanceprobleme überhaupt und das Dilemma wäre noch sehr viel größer, hätte man nicht verschiedene Maßnahmen der Gegenwehr ersonnen. Dazu zählen etwa Plattenverbünde, die die I/O-Last auf viele Spindeln verteilen können, oder und vor allem Caches, die Plattenzugriffe durch Hauptspeicherzugriffe substituieren. Getreu dem Motto: "The only good fast read is the one you didn't have to do." Das Lesen aus dem Cache kostet nur Mikrosekunden, von der Platte mindestens eine Handvoll Millisekunden, also wenigstens das Tausendfache.

Damit lässt sich der Leistungsunterschied zumindest ein wenig angleichen, allerdings um den Preis einer höheren Komplexität. Ein Plattenzugriff durchläuft auf seinem Weg von der Applikation über das Filesystem den Page Cache des Betriebssystems, den Block I/O Layer, den I/O Scheduler, den Gerätetreiber, die Plattenelektronik bis schließlich zur Magnetschicht der Festplatte zahlreiche Ebenen ( Abbildung 3 ), die zwar oft nichts voneinander wissen, unter Umständen aber gleichwohl jeweils auf ihre Art versuchen, die Performance zu verbessern. Das kann durchaus nach hinten losgehen. Auch das Tuning stößt hier an Grenzen, weil sich die verschiedenen Effekte nur sehr schwer einzeln messen und beeinflussen lassen. Komplexe Disk-Setups, etwa in einem SAN, können eine Performanceprognose fast unmöglich machen.

Abbildung 3: Der I/O-Stack von Linux ist ein komplexes Gebilde.

Eine der Faustregeln, die es für das Plattentuning dennoch gibt, heißt Lastverteilung. Jede einzelne Platte sollte höchstens zu einem Drittel ausgelastet sein, wenn man Wert auf Geschwindigkeit legt. Dann kann sie zwei von drei Lese- oder Schreibanforderungen sofort bedienen. Außerdem helfen schnelle Platten und große Caches. Benutzt der Admin RAID-Konstruktionen, sollte er deren Auswirkungen auf die Performance im Blick haben. So steigert Striping (RAID 0) oder eine davon abgeleitete Mischform (RAID 01, RAID 10 und so weiter) die Transferrate, dagegen bremst RAID 5 das Schreiben wegen der dabei nötigen Prüfsummenberechnung deutlich.

Zwar kann man auch versuchen, mit Filesystem-Parametern zu experimentieren oder mit der Auswahl und Einstellung des I/O-Schedulers [6] , allerdings ergeben sich dabei im Zusammenwirken mit allen anderen Komponenten nicht immer nachvollziehbare Resultate.

Regeln für den RAM

Hauptspeicher kann man eigentlich nicht genug haben – wäre er nicht teuer. Wer sich keinen maximalen Hauptspeicherausbau zur Prophylaxe leisten kann, für den kommt es stattdessen darauf an, den Speicher klug zwischen User-Prozessen, Shared Memory und Filesystem Cache auszubalancieren.

Unter Linux kann nicht jeder virtuellen Speicherseite von Anfang an bereits ein physisches RAM-Äquivalent gegenüberstehen, denn es gibt viel mehr virtuellen als physischen Hauptspeicher. Das Mapping von virtuellen auf physische Seiten geschieht deshalb erst zum Zeitpunkt des ersten Zugriffs (Demand Paging). Versucht das OS dabei auf eine virtuelle Speicherseite zuzugreifen, der momentan kein physischer Speicher zugeordnet ist, kommt es zu einem sogenannten Page Fault. Um ihn zu beheben, muss dann die fragliche physische Seite von der Festplatte, auf der sie ausgelagert war, wieder eingelesen und dem virtuellen Gegenstück zugewiesen werden. Beim Swapping wird statt einer einzelnen Seite der gesamte Seitensatz eines Prozesses ausgelagert oder wieder eingelesen.

Paging ist mithin normal und notwendig, aber eine zu hohe Pagingfrequenz oder Swapping können Anzeichen von zu knappem RAM sein. Der Swapspace sollte übrigens nicht ausgehen, denn dann bleibt Linux stehen.

Schließlich ist auch die sogenannte Scan-Rate ein Indiz. Sie gibt an, wie oft der freie Speicher in einem bestimmten Zeitintervall unter den Wert »lostfree« gefallen ist und sich der Pagescanner deshalb auf die Suche nach wenig benutzten Speicherseiten begeben musste, die er wiederverwenden kann. Unter Solaris gibt »vmstat« diese Scanrate direkt aus, unter Linux findet man Vergleichbares mit »sar -B« . Weiteren Aufschluss über die Memory-Statistik gibt »vmstat« mit der Option »-s« .

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023