A. Willemer
Wie werde ich UNIX-Guru
|  | | I ANWENDUNG |
Know-How für Unix/Linux-User: Einführung, Shell, Befehle, Hilfe, Arbeit mit Dateien, Editoren, Reguläre Ausdrücke, nützliche Tools, Hardware.
|
| II ADMINISTRATION |
Tools, Systemstart, Benutzer verwalten, Hardware konfigurieren, Software installieren, Datensicherung, Tuning, Kernel
|
| III NETZWERK |
Client/Server Systeme, TCP/IP, Routing, IPv6, Internet-Dienste, DHCP, Webserver, Firewalls
|
| IV DAS X-WINDOW SYSTEM |
Die grafische Oberfläche von UNIX einrichten und nutzen
|
| V PROGRAMMIERUNG VON SHELLSKRIPTEN |
Automatisieren von Tasks durch Shell-Skripte.
|
| VI PERL |
Interpreter, Syntax, Variablen, Steuerung, Funktionen, UNIX-Aufrufe, GUIs mit Tk
|
| VII PROGRAMMIERWERKZEUGE |
C-Compiler, Analyse-Tools, CVS, yacc, diff
|
| VIII UNIX-SYSTEMAUFRUFE |
UNIX-Befehle in eigenen Programmen nutzen
|
| IX LITERATUR |
Weiterführende Literatur zu UNIX und LINUX
|
| |
Die Einschätzung, dass die Maschine langsam ist, reicht nicht aus, um
Gegenmaßnahmen zu ergreifen. Man muss schließlich die Beschränkung beseitigen,
die die Leistung am meisten einschnürt.
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, wie viel 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, erhält man den Zeitraum, den die Messung
abdeckt.
vmstat erzeugt eine Ausgabe, die wie folgt 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
Folgende Werte werden dabei gemessen:
- [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), cs (context switch per second)
- [cpu:] Verteilung der CPU-Last auf user (us), system (sy) und idle (id).
Beispielsweise deutet ein starkes Swapping bei gleichzeitiger hoher
CPU-Belastung im Systembereich auf zu wenig Hauptspeicher hin.
Besonders interessant werden diese Werte, wenn man sie zu verschiedenen
Zeitpunkten des Tages aufnimmt. Dadurch kann man erkennen, welche Zahlen
sich überdurchschnittlich stark 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 die Geschäftsleitung nach dem Verantwortlichen ruft.
Im folgenden Abschnitt über sar wird gezeigt, wie man ein solches
Analysetool in die crontab (siehe S. crontab)
stellt. Ähnlich kann man auch mit vmstat arbeiten.
Ein anderes noch umfangreicheres Beobachtungstool gibt es bei System V
Maschinen. Es 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 eines Vergleichs zwischen Last- und
Ruhezeiten ermöglichen. Da sar recht gute
Informationen liefert, wenn etwas
schief läuft, sollte man es in jedem Fall 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 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, ist ein Datensammler erforderlich.
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, das normalerweise
in die crontab (siehe S. 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
Das Skript sa2 erzeugt aus den sa-Dateien einen täglichen
Bericht in reinem Textformat, den es unter fast gleichem Namen anlegt. Das
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 die
Puffer und die Peripherie.
- [-c] Berichtet über Systemcalls, unter anderem über 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 Semaphore
- [-n] Namenscache-Statistik
- [-p] Paging-Aktivitäten. Diese Statistik gibt Auskunft über die Häufigkeit
des Ladens ausgelagerter Speicherbereiche.
- [-q] Gibt Auskunft über die Prozesslisten.
- [-R] Prozessaktivitäten: beispielsweise 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 Prozess-, i-node- und Dateitabellen.
- [-w] Swapping und Switching: pswch/s zeigt die Anzahl der Prozesswechsel
pro Sekunde.
- [-y] TTY-Devices
Die CPU-Last muss nach User- und nach Systemlast getrennt beurteilt werden.
Beide haben unterschiedliche Ursachen. Die Systemlast sagt, dass die Maschine
lange mit Systemaufrufen wie dem Laden von Dateien, der Netzkommunikation
oder Ähnlichem zu tun hat. Dabei tragen beispielsweise beim Laden einer Datei
nicht so sehr die Plattengeschwindigkeit, sondern der Aufwand beim Verwalten
der Zugriffe in die CPU-Systemlast bei. 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 dass das
System
ständig mit dem Swappen befasst ist. Es kann aber auch bedeuten, dass zu wenig
Puffer für die Dateioperationen zur Verfügung steht.
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 Kompilierung
auf Entwicklermaschinen können kurzfristig bis zu 100% CPU-Auslastung im Userbereich
entstehen. Bei den üblichen Verwaltungsprogrammen auf Servern sind
CPU-Belastungen von 10% bis 20% bereits relativ viel. Wenn der Wert darüber
hinausgeht, muss man feststellen, welches Programm wie viel CPU-Zeit
beansprucht. Zu diesem Zweck gibt es Programme wie top (siehe S.
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 (siehe S. polling) CPU-Zeit verschwenden.
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 (beispielsweise 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 heraufgesetzt 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.
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 steht. Sofern die ausgelagerten Prozesse
nicht aktiv werden, können sie getrost dort bleiben, wo sie sind.
| |
|
|
| Ihre Meinung? |
|
|
|
|
| | |
| |
| Shopping |
|
Versandkostenfrei bestellen in Deutschland und Österreich
 Info
|
|
| |
| |
|
