UNIX-Tuning

Willemers Informatik-Ecke

Keine Wunder erwarten

Jeder Computerbenutzer träumt davon, mit ein paar gekonnten Eingriffen in das System dem Rechner Flügel zu verleihen. Jede Woche findet man solche Tipps in großer Vielfalt in den Computerzeitschriften und nur der nachdenkliche Anwender stellt sich vielleicht hin und wieder die Frage, warum den Herstellern nicht in den Sinn gekommen ist, ihr System auf diese Art zu beschleunigen.

Tatsächlich gibt es einige Hinweise, die ein etwas flotter laufendes System bewirken. Aus einer überlasteten Maschine machen diese Maßnahmen aber noch keinen Raser. Im Normalfall helfen Eingriffe in die Konfiguration, die ursprüngliche Geschwindigkeit zu erhalten oder die Last so zu verteilen, dass kein Flaschenhals entsteht.

Ursache suchen

Irgendwann muss man mit Hardware aufrüsten. Bevor man aber einkauft, sollte man das System beobachtet haben, damit man auch sicher weiß, wo der Flaschenhals sitzt. So ist beispielsweise der beinahe immer richtige Tipp, den Speicher aufzurüsten, unsinnig, wenn auf der Maschine soviel Speicher vorhanden ist, dass kein Swapping feststellbar ist.

Optimierung des Dateisystems

Der Einfluss des Dateisystems auf den Gesamtdurchsatz ist natürlich davon abhängig, für welchen Einsatz die Maschine gedacht ist. Eine CAD-Workstation und auch eine Entwicklungsmaschine für einen Softwareentwickler werden von der Beschleunigung eines Dateisystems nicht profitieren. Dagegen werden alle Programme, die mit Daten in größerem Umfang hantieren, dadurch zentral beeinflusst.

Überfüllung der Dateisysteme vermeiden

Ist die Platte über 90% gefüllt, wird das die Performance beeinflussen. Da nur wenig Platz ist, werden alle Lücken aufgefüllt, die sich durch das Löschen von Dateien im Laufe der Zeit gebildet haben. Nach einiger Zeit sind diejenigen Dateien, die regelmäßig geändert werden, die Lückenfüller der Platte und verursachen heftige Bewegungen des Schreib- Lesekopfs. Man spricht in diesem Falle von Fragmentierung oder Zerclusterung eines Dateisystems.

Auf einer zentralen Servermaschine wird man die Dateisysteme, auf denen Daten bewegt werden, möglichst unter 80%, besser unter 70% halten.

Fragmentierung beseitigen

Defragmentierungssoftware, wie man sie vom PC her kennt, wird der eine oder andere unter UNIX vielleicht vermissen. Der Grund dafür ist, dass man sie unter UNIX normalerweise nicht braucht. Gibt es tatsächlich Grund zu der Annahme, dass man die Platte durch Fragmentierung zu langsam ist, wird man über kurz oder lang eine größere Platte kaufen und die Daten beispielsweise per tar auf die neue Platte kopieren. Bei diesem Neuaufspielen der Daten werden alle Fragmentierungen beseitigt. Alternativ können Sie natürlich auch eine Bandsicherung durchführen, mit mkfs oder newfs ein neues Dateisystem erstellen und die Bandsicherung zurückholen.

Blockgröße

nur auf älteren Systemen

Auf älteren Systemen kann man die Blockgröße noch selbst als Parameter beim Erzeugen des Dateisystems mit mkfs festlegen. Typischerweise liegt sie zwischen 512 Byte und 4 KB. Je grösser der Block ist, den das System mit einem mal liest, desto geringer wird der Einfluss der langsamen Plattenzugriffe auf die gesamte Dateioperation. Ab einer gewissen Blockgrösse allerdings kippt dieser Wert wieder, wenn zu oft mehr geladen wird, als tatsächlich benötigt wird.

So groß der Block ist, so groß ist dann auch die kleinste Datei, da die Platte immer blockweise belegt wird. Bei vielen kleinen Dateien wird der verschwendete Speicherraum entsprechend groß.

Moderne Dateisysteme sind in der Lage durch dynamische Caches und Aufspaltung von Blöcken für kleine Dateien, diese Tuningmaßnahmen selbst zu übernehmen.

Verteilung auf mehrere Platten

Spurwechsel durch Verteilung verringern

Besitzt man mehrere physische Platten, kann man durch geschicktes Verteilen der Dateien einen Performancegewinn erzielen. Wenn zwei ständig im Wechsel zugegriffene Dateien auf einer Platte liegen, muss der Schreiblesekopf des Laufwerkes ständig zwischen diesen beiden Dateien hin- und herpositionieren. Kann man die beiden Dateien auf zwei Platten verteilen, werden diese Positionierungen eingespart. Gerade unter UNIX ist das Verteilen auf mehrere Platten extrem einfach. Durch einen symbolischen Link merken die zugreifenden Programme nicht einmal, dass eine Datei nicht mehr an der ursprünglichen Stelle liegt. Die Indirektion durch den Link ist minimal und wird auch nur einmal beim Öffnen benötigt. Danach arbeitet das Programm mit einem Dateihandle direkt auf der Datei.

Es versteht sich eigentlich von selbst, dass ein Verteilen der Dateien auf mehrere Partitionen der gleichen Platte kontraproduktiv ist und genau das Gegenteil erreicht.

Eigenes Dateisystem für /tmp

Das Verzeichnis /tmp kann auf eine eigene Platte gelegt werden. Dies bringt auf Systemen etwas, die das Verzeichnis intensiv nutzen, wie beispielsweise bei der Compilierung. Es wird eine höhere Geschwindigkeit erreicht, da das ständige Schreiben und Löschen zu einer starken Zerclusterung führt. Da /tmp aber jederzeit gelöscht werden kann, ist es möglich, durch rekursives Löschen des kompletten Verzeichnisses mit einem unzerstreuten System weiter zu arbeiten. Ferner ist der Vorteil, dass im Bereich des /tmp bei einem Absturz häufig ein unzusammenhängendes Dateisystem entsteht. Da das komplette Dateisystem /tmp bedenkenlos gelöscht werden kann, ist der Schaden nur gering.

Eigenes Dateisystem

Ist ein eigenes Dateisystem für /tmp nicht praktikabel, sollte man von Zeit zu Zeit im Single-User-Modus das Verzeichnis komplett entfernen und wieder neu anlegen, da so auch das Verzeichnis wieder geleert wird. Insbesondere wenn die Größe des Verzeichniseintrags im ls -ld auffallend groß ist, sollte man diese Maßnahme ergreifen.

RAM-Disk

Bei den eben erwähnten Entwicklermaschinen, bei denen der Compiler oft das Verzeichnis /tmp benutzt, wird manchmal zur Beschleunigung das Verzeichnis in eine RAM-Disk gelegt. Natürlich macht das nur Sinn, wenn die Maschine üppig mit Speicher ausgestattet ist.

Übervolle Verzeichnisse entsorgen

Verzeichnisse sind linear

Verzeichnisse sind lineare Strukturen. Wird eine Datei angelegt, wird sie hinten im Verzeichnis angelegt. Die Einträge sind also nicht alphabetisch geordnet, wie es bei der Anzeige erscheint. Also wird bei der Suche nach einer Datei die Liste von vorn nach hinten durchgegangen. Da die Suche nach dem Dateinamen nur relevant wird, wenn die Datei immer wieder geöffnet und geschlossen wird, fallen Probleme in diesem Bereich nicht so sehr auf. Wenn Verzeichnisse aber sehr voll werden, werden die Zugriffe immer langsamer. Besonders kritisch wird es, wenn in Verzeichnissen regelmäßig gelesen und geschrieben wird.

Verzeichnisgrößen beachten

Ein Zeichen, dass ein Verzeichnis überlastet ist, ist seine Größe. Man kann dies leicht durch einen ls -ld prüfen. Im Allgemeinen werden die meisten Verzeichnisse gleich groß sein. Beim /dev und beim /tmp dürfte man bereits sehen, dass sich darin deutlich mehr Dateien befinden. Verzeichnisse werden aber niemals wieder kleiner. Um ein Verzeichnis, in dem viel geschrieben und gelöscht wurde, wieder auf eine normale Größe zu bringen, sollte man zunächst eine Sicherung der Daten beispielsweise per tar durchführen. Anschließend per rm -r den gesamten Ast inklusive Verzeichnis löschen und dann die gesicherten Dateien wieder an den Ort zurück holen. Dabei wird das Verzeichnis neu angelegt.

Wissen, wo der Schuh drückt

Die Einschätzung, dass die Maschine langsam ist, reicht nicht aus, um Gegenmaßnahmen zu ergreifen. Man muss schließlich die Beschränkung lockern, die die Leistung am meisten einschnürt.

vmstat

vmstat ist ein Programm, das auf fast jeder UNIX-Maschine verfügbar ist. Es wertet diverse Kernelprotokolle aus und stellt sie dar. Dabei werden die Prozesse, der Speicher, das Swapping, der Plattendurchsatz und die CPU-Belastung beobachtet. Der Aufruf lautet 

vmstat Sekundenabstand  Wiederholungen

Der erste Parameter bestimmt, wieviel Zeit in Sekunden zwischen den Ausgaben vergehen soll. Aufgrund der vielen Daten, die erhoben werden, sollte der Abstand nicht allzu gering sein, damit vmstat nicht selbst die Messung verfälscht. Der zweite Parameter bestimmt die Anzahl der Messungen. Multipliziert man die beiden Werte, hat man den Zeitraum, den die Messung abdeckt. vmstat erzeugt eine Ausgabe, die wie die folgende aussieht. 

   procs                      memory    swap          io     system         cpu
 r  b  w   swpd   free   buff  cache  si  so    bi    bo   in    cs  us  sy  id
 1  0  0    512  12932  90984 116120   0   0     0     0  103   407   5   0  95
 1  0  0    512  12932  90984 116120   0   0     0     0  123   502   4   0  96

Dabei sind die einzelnen gemessenen Werte:

procs:
zählt r (warten auf Laufzeit), b (uninterruptable sleeping), w (swapped processes)
memory:
aus dem swpd (virtueller Speicher), free (idle), buff und cache
swap:
swap in (si) swap out (so)
io:
blocks in (bi) blocks out (bo)
system:
in (Interrupts per second), ce (context switch per second)
cpu:
Verteilung der CPU-Last auf user, system und idle. Beispielsweise deutet ein starkes Swapping bei gleichzeitiger hoher CPU-Belastung im Systembereich auf zuwenig Hauptspeicher hin.

Die Zahlen beobachten

Besonders interessant werden diese Werte, wenn man sie zu verschiedenen Zeitpunkten des Tages aufnimmt. Dadurch kann man erkennen, welche Zahlen sich überdurchschnittlich verändern. Es ist wichtig zu wissen, welche Werte für die Maschine im Ruhezustand typisch sind. Welche Ergebnisse erhält man bei einer beschäftigten Maschine, die aber noch zügig reagiert und wie sehen die Zahlen aus, wenn die Maschine überlastet ist? Ein Gefühl für diese Zahlen sollten Sie als Administrator möglichst schon haben, bevor man nach dem Verantwortlichen ruft.

In die crontab stellen

Im folgenden Abschnitt über sar wird gezeigt, wie man ein solches Analysetool in die crontab stellt. Ähnlich kann man auch mit vmstat arbeiten.

sar

sar gehört zu System V

Ein anderes noch umfangreicheres Beobachtungstool bringen System V Maschinen mit und heißt sar (system activity report). Es ist normalerweise nicht aktiviert. Man muss es also in Betrieb nehmen, um Daten über das System zu sammeln. sar erfasst Aktivitätszähler, die das System führt. Vor allem erstellt sar regelmäßige Statistiken, die die Auswertung im Vergleich zwischen Last- und Ruhezeiten ermöglichen. Da sar recht gute Informationen liefert, wenn etwas schiefläuft, sollte man es in jedem Falle starten, wenn eine neue Maschine in Betrieb genommen wird, wenn man Probleme hat, deren Herkunft unerklärlich sind oder wenn sich Dinge grundsätzlich ändern, wie der Einsatz neuer Software oder Hardware.

Die gesammelten Daten werden in dem Pfad /var/adm/sa gesammelt. Eventuell muss das Verzeichnis erst angelegt werden. Darin legt sar sich für jeden Tag des Monats eine Datei mit dem Präfix sa an. Für den 12. des Monats wäre dies also sa12.

Damit diese Dateien entstehen, bedarf es eines Datensammlers. Dieser heißt sadc und wird in der rc-Datei des Systems gestartet. 

/usr/lbin/sa/sadc /var/adm/sa/sa`date +%d`

Darüber hinaus verbirgt er sich im Skript sa1, der normalerweise in die crontab des root eingetragen wird (vgl. Manpage zu sa1). 

0 *    * * 6,0 /usr/lib/sa/sa1 3600 /var/adm/sa/sa`date +%d`
0 8-17 * * 1-5 /usr/lib/sa/sa1 3600 /var/adm/sa/sa`date +%d`
0 8-17 * * 1-5 /usr/lib/sa/sa1 1200 3 /var/adm/sa/sa`date +%d`
5 18   * * 1-5 /usr/lib/sa/sa2 -s 8:00 -e 18:01 -i 1200 -A

Der Skript sa2 erzeugt aus den sa-Dateien einen täglichen Bericht in reinem Textformat, die er unter fast gleichem Namen anlegt. Der Präfix ist allerdings hier sar statt sa.

Zu Auswertung der sa-Dateien wird das Kommando sar verwendet. Durch seine Optionen kann bestimmt werden, welche Informationen angezeigt werden.

-A
Alle Optionen auf einmal einschalten.
-a
Dateizugriffe. Zeigt iget/s, namei/s und dirblk/s
-B
Kopierpufferaktivitäten
-b
Pufferaktivitäten:

bread/s, bwrite/s sind die Blockzugriffe zwischen den Systempuffern und der Peripherie.

lread/s, lwrite/s sind die Zugriffe auf die Systempuffer.

%rcache, %wcache ist das Verhältnis zwischen Zugriffen auf den Puffern und der Peripherie.

-c
Berichtet über Systemcalls, unter anderem fork und exec.
-d
Zeigt die Aktivität einzelner Blockdevices. Diese Informationen können hilfreich sein, um Zugriffe auf mehrere Platten zu verteilen.
-g
Serielle Schnittstellen.
-h
Pufferstatistiken
-m
Messages und Semaphoren.
-n
Namenscache Statistik
-p
Pagingaktivitäten. Diese Statistik gibt Auskunft über die Häufigkeit der Einladens ausgelagerter Speicherbereiche.
-q
Gibt Auskunft über die Prozesslisten.
-R
Prozessaktivitäten: beispielsweie Häufigkeit, wie oft der Prozessumschalter gestartet wurde.
-u
CPU-Auslastung: %usr, %sys, %wio, %idle.

usr ist die Auslastung durch Anwendungsprogramme, sys ist der Verbrauch durch Systemfunktionen. wio ist das Warten auf I/O Funktionen. Unter idle steht die Zeit, die sich die CPU gelangweilt hat. Diese sollte nur in Ausnahmefällen unter 50% fallen. Insbesondere, wenn dieser Wert über 90% steigt, besteht der Verdacht, dass ein Programm Polling betreibt oder dass das System ein Problem hat.

-v
Status der Größen der Prozess-, Inode- und Dateitabellen.
-w
Swapping und Switching: pswch/s zeigt die Anzahl der Prozesswechsel pro Sekunde.
-y
TTY-Devices.

Gegenmaßnahmen

CPU Systemlast

Die CPU-Last muss nach User- und die Systemlast getrennt beurteilt werden. Beide haben unterschiedliche Ursachen. Die Systemlast sagt, dass die Maschine viel Zeit mit Systemaufrufen wie dem Laden von Dateien, der Netzkommunikation oder ähnlichem zu tun hat. Dabei fließen beispielsweise beim Laden einer Datei nicht so sehr die Plattengeschwindigkeit, sondern der Aufwand beim Verwalten der Zugriffe in die CPU-Systemlast. Dazu gehört beispielsweise das Prüfen von Sperren oder Quota. Eine hohe Systemlast kann bedeuten, dass zu wenig RAM in der Maschine vorhanden ist und das System ständig mit dem Swappen befasst ist. Es kann aber auch bedeuten, dass zuwenig Puffer für die Dateioperationen zur Verfügung steht.

CPU-Last User

CPU-Last im Userbereich bedeutet, dass Programme sich stärker mit ihrem Code als mit den Daten beschäftigen. Das geht in Ordnung, wenn es Programme sind, die beispielsweise dreidimensionale Bilder berechnen. Auch bei der Compilierung auf Entwicklermaschinen können kurzfristig bis zu 100% CPU Auslastung im Userbereich entstehen. Bei den üblichen Verwaltungsprogrammen auf Servern sind CPU-Belastungen von 10%-20% bereits relativ viel. Wenn der Wert darüber hinausgeht, muss man feststellen, welches Programm wieviel CPU-Zeit beansprucht. Zu diesem Zweck gibt es Programme wie top, das quasi eine Hitparade der Prozesse darstellt. Verfügt man nicht über ein derartiges Programm, kann man auch durch mehrfaches Anzeigen der Prozessliste mit ps die schuldigen Prozesse finden. Da ps immer nur die insgesamt angefallene CPU-Zeit anzeigt, muss man die Differenz der Messungen bilden. Ein Programm, das auffallend viel Zeit verbraucht, kann entweder völlig durcheinander sein oder durch so genanntes Polling CPU-Zeit verschwenden.

I/O Last und Puffer

Im I/O-Bereich zeigt sich die Auslastung der Dateisysteme. Interessant ist die Größe des Cache. Ungepufferte Plattenzugriffe sind extrem langsam. Wenn die Puffergröße nicht ausreicht, werden spürbare Performanceeinbrüche die Folge sein. In einigen älteren Systemen (z. Bsp. SCO 3.x) muss der Plattencache statisch als Kernelparameter festgelegt werden. Für einen Firmenserver ist der Defaultwert oft viel zu klein und muss unbedingt erhöht werden. Bei Systemen mit dynamischer Speicherverteilung wird der Cache natürlich nicht erhöht, wenn dadurch der Hauptspeicher so knapp wird, dass das Swapping erheblich zunimmt. In solch einem Fall ist ein Speicherausbau dringend geboten.

Speicherverwaltung

Dass der freie Hauptspeicher einer Maschine mit dynamischer Speicherverwaltung gering ist, sollte niemanden alarmieren. Aus der Sicht des Speichermanagers ist freier Speicher nur ein unnützer Stromfresser und er wird versuchen, die wertvolle Ressource auf die Plattenpuffer zu verteilen. Dort macht er sich nützlich, indem er Dateizugriffe beschleunigt. Auch ist es völlig normal, dass erhebliche Teile des Swapbereichs belegt sind, obwohl freier Speicher zur Verfügung stünde. Sofern die ausgelagerten Prozesse nicht aktiv werden, können sie getrost dort bleiben, wo sie sind.

Diese Seite basiert auf Inhalten aus dem Buch Arnold Willemer: Wie werde ich UNIX-Guru
Verlagsrechte bei galileo computing

Homepage (C) Copyright 2002 Arnold Willemer