| orm@doc-tcpip.org | Erstellt: März 2006 - Letzte Modifikation: Januar 2009 |
Auf synchronen IO muß die Applikation warten. Im Fall des asynchronen IO gibt die Applikation über ein dafür vorgesehenes Device und entsprechende Systemcalls den IO in Auftrag, kann damit den IO als erledigt betrachten und weiterarbeiten.
Der tatsächliche, physikalische IO wird dann vom Kernel asynchron (aber zeitnah) abgearbeitet.
Eine Applikation kann verschiedene, asynchrone IO Vorgänge gegen ein File oder Device starten. Aufgrund der asynchronen Natur des IO ist es die Sache der Applikation, voneinander abhängige Schreibvorgänge richtig zu ordnen. Der Kernel arbeitet die Anforderungen ehr zufällig nach freien Kapazitäten ab.
Die Applikation wird dadurch schneller, besonders, wenn man auf raw logical volumes oder JFS2 mit cio-gemounteten FS zugreift.
Aufgrund der asynchronen Natur, also der Entkopplung von Schreibauftrag durch die Applikation und effektivem Schreiben auf die Platte durch das OS, ist es der Applikation möglich, gleichzeitig dasselbe Device oder dasselbe File zu beschreiben (zumindest sieht das für die Applikation so aus).
Wenn die Applikation entsprechende Systemcalls (Subroutinen aio_read(), aio_write(), lio_listio() bzw. 64-Bit Versionen) auslöst, so wird pro Anforderung ein Control-Block im Adress-Bereich der Applikation angelegt. In diesem Block findet sich eine Kennadresse (Handle), über den der Status abgefragt werden kann und Rückgabewerte ausgelesen werden können.
Der Systemcall legt die Anforderung auf eine Queue und kehrt dann zur Applikation zurück. Ein Kernel-Prozess (kproc) nimmt die Anforderung von der Queue und setzt sie um.
Dabei ist es entscheidend, wieviele aio-Serverprozesse gestartet worden sind (aioserver). Die Zahl dieser Kernel-Prozesse bestimmt die Zahl der Disk IO, die simultan bearbeitet werden können.
Das AIO Subsystem ist in /usr/include/sys/aio.h beschrieben. Es gibt eine AIX Version und eine POSIX konforme Version, die beide unterschiedliche Devices haben und unterschiedliche Features aufweisen.
Installiert sein muß folgendes Paket: bos.rte.aio
Das Device sieht man mit
lsdev -Cc aio lsdev -Cc posix_aioDiese Devices müssen "available" sein.
pstat -a | grep posix_aio pstat -a | egrep ' aioserver'
JFS und JFS2 senden jeden IO durch die kprocs der aio-Server (weil es Block-Devices sind, Daten also blockweise geordnet schreiben). Nutzt man raw logical Volumes, so wird der IO nicht durch die kprocs geleitet (weil es Character-Devices sind, Daten also im Prinzip Byte für Byte geschrieben werden) - der IO geht dann direkt auf das Device. Die Anzahl der kprocs ist in diesem Fall für die Performance also unerheblich. Es wird aber trotzdem asynchron geschrieben, nur koordiniert das die Applikation selbst.
Das ist die "Fast Path Option", die man Abschalten kann. Das ist nur für Testzwecke sinnvoll; der IO geht dann über die kprocs, und der Zugriff auf das raw logical Volume wird langsamer.
Generell sind die Statistiken aus dem vmstat, die sich auf den Platten IO beziehen, nicht gut geeignet, um Aussagen bezüglich des IO Subsystems zu machen. Bei SMP Systemen werden die Statistiken für us, sy, id und wa über alle CPUs gemittelt. Beim Wert für wa macht das Schwierigkeiten. Ist ein IO-Vorgang aktiv, so wird die Zeit aller Prozessoren, die in einer Zeiteinheit "idle" waren, pauschal als "io wait" verbucht.
Es gibt 3 Daumenregeln:
Man setzt die maximale Anzahl der Server auf 10* die Zahl der Platten im gleichzeitigen Zugriff (Maximalwert ist 80). Die minimale Anzahl der Server soll auf die Hälfte gesetzt werden.
Man setzt die maximale Anzahl der Server auf 80 und die minimale Anzahl auf 1. Dann läßt man die Maschine/Applikation normal laufen und schaut, wieviele Server nachgestartet wurden. Nun setzt man die aktuelle Zahl plus 10, und die minimale Anzahl Server setzt man auf die gefundene Anzahl minus 10.
Vor hoher IO Aktivität sieht man sich vmstat -s an. Das Feld "iodone" zeigt, wieviele physikalische IO Vorgänge in einer Zeiteinheit beendet wurden. Dann erhöht man die Anzahl der Server und prüft, ob man mehr IO schafft.
Zu 1 - Die Datenstruktur "aiocb" enthält ein 64 bit Feld für den Offset der Datenübertragung. Das 32 bit Feld läßt nur Files bis 2 GB -1 zu. Findet sich alles in /usr/include/sys/aio.h
Zu 2 - Die Applikation gibt die IO Anforderung ab und kann dann weiterarbeiten. Die Anforderung ist dann auf einer Queue und wird abgearbeitet. Die Applikation muß einen Control-Block anlegen, in dem Statusinformationen abgelegt werden.
Zu 3 - Die Applikation hat drei Möglichkeiten, den Status bzw. das Ende des IO zu erfahren:
Zu 4 - Eine Anforderung kann in der Regel nicht mehr abgebrochen werden, wenn der IO tatsächlich schon begonnen hat.
0:/root # lsattr -El aio0 autoconfig available STATE to be configured at system restart True fastpath enable State of fast path True kprocprio 39 Server PRIORITY True maxreqs 8192 Maximum number of REQUESTS True maxservers 64 MAXIMUM number of servers per cpu True minservers 32 MINIMUM number of servers True
Bedeutung:
kprocprio: Hier kann man die Priorität der AIO kprocs einstellen.
maxreqs: Die maximale Anzahl asynchroner IO Anforderungen, die zu einem Zeitpunkt offen sein dürfen. Also alle Anforderungen, die gerade bearbeitet werden, sowie die sich auf der Queue befindlichen.
Die maximale Anzahl findet sich als AIO_MAX in /usr/include/sys/limits.h.
Dieser Parameter braucht einen Reboot und ist permanent.
Setzen per chdev:
chdev -l aioX -a maxreqs=xxx
maxservers: Setzt die Anzahl der Server-Prozesse (kprocs), die pro Prozessor gestartet werden können. Ein solcher Prozess bearbeitet eine IO Anforderung - daher sollte die Zahl der Anzahl der zu erwartenden, parallelen IO Anforderungen entsprechen (plus eine kleine Sicherheitsmarge).
Per Default werden pro Prozessor 10 Server-Prozesse gestartet.
Dieser Parameter braucht einen Reboot und ist permanent.
Setzen per chdev:
chdev -l aio0 -a maxservers=xxx
minservers: Setzt die Anzahl an Server-Prozessen (kprocs), die beim laden der aio-Kernel-Extension pro Prozessor gestartet werden. Ein kleiner Wert ist zu empfehlen, da das System die Server-Prozesse bei Bedarf nachstartet (bis maxserver erreicht ist). Standard ist 1 Server-Prozess pro Prozessor.
Dieser Parameter braucht einen Reboot und ist permanent.
Setzen per chdev:
chdev -l aio0 -a minservers=xxx
Installiert sein muß folgendes Paket: bos.rte.aio
Die wichtigen Unterschiede bzw. Neuerungen:
Kernel Extension für AIO: Das AIO Subsystem ist in AIX 6 in den Kernel integriert worden. Es wird in AIX 6 eine Kernel-Extension beim Booten geladen. Es sind daher keine Prozesse aktiv - erst, wenn AIO angesprochen wird, starten Prozesse. Das wird überwacht und gesteuert durch spezielle Kernel-Threads (aioLpools und aioPpools). Wenn kein AIO aktiv ist, sind nur die Extensions und die Threads sichtbar:
root@sv803:/root # genkex |grep aio
4ba0000 20000 /usr/lib/drivers/posix_aiopin
4b80000 20000 /usr/lib/drivers/posix_aio.ext
4b60000 20000 /usr/lib/drivers/aiopin
4b40000 20000 /usr/lib/drivers/aio.ext
root@sv803:/root # pstat -a | grep aio
22 a 16058 1 16058 0 0 1 aioPpool
28 a 1c05e 1 1c05e 0 0 1 aioLpool
Es gibt zwei AIO Subsysteme, ein klassisches (Legacy) AIO, und ein
POSIX-konformes. Beide laufen parallel, und der Entwickler einer Anwendung
entscheided, welches System er nutzen möchte. Daher sind die Extensions
und Threads für AIO doppelt vorhanden. Die Unterscheidung erfolgt durch das
Wörtchen posix bzw. durch ein subtil untergebrachtes P oder
L.
Kein Device für AIO: Es gibt kein eigenes Device für AIO, also die Abfragen per lsdev kommen leer zurück - kein Grund zur Panik, da es ja jetzt eine automatisch geladene Kernel-Extension gibt. Allerdings ein Problem für die Installations-Routinen einer Reihe von Software Paketen, da diese nach dem aktiven Device suchen.
Kein eigenen Kommandos oder SMIT Panels für AIO: Die SMIT-Seiten und AIO spezifischen Kommandos sind alle entfernt worden. Die Tuning-Parameter sind im ioo-Kommando sichtbar.
Kein Reboots wegen AIO: In der neuen Implementation ist AIO ab dem Booten verfügbar, und alle Tuning Parameter sind mittlerweile dynamisch - kein Reboot zur Aktivierung mehr nötig.
Wie schon ausgeführt werden die AIO Server Prozesse jetzt über die Kernel Extension on demand gestartet. Abhängig von der Last bewegt sich deren Anzahl zwischen den Parametern minserver und maxserver, wobei diese jetzt per CPU betrachtet werden. Dann gibt es noch einen Parameter, der begrenzt, wie lange ein AIO Server aktiv gehalten wird, wenn der IO erledigt ist: aio_server_inactivity. Nach diesem Timeout wird der AIO Server abgebaut. Die gesamte Anzahl an ausstehenden asynchronen IOs begrenzt der Parameter aio_maxreqs. Der Parameter aio_active it statisch, kann also nur vom System geändert werden. AIX setzt hier eine Eins, wenn die AIO Server nach der ersten Anforderung angestartet wurden und so im Kernel Memory Platz brauchen. Per Default sind folgende Werte gesetzt:
root@sv803:/root # ioo -a |grep aio
aio_active = 0
aio_maxreqs = 65536
aio_maxservers = 30
aio_minservers = 3
aio_server_inactivity = 300
Daneben gibt es noch eine Reihe Tuning Parameter, die im Normalfall nicht
verändert werden sollen (restricted tunables). Hier ist zum Beispiel
festgelegt, das die Fast Path Option per Default gesetzt wird.
root@sv803:/root # ioo -aF |grep aio
aio_fastpath = 1
aio_fsfastpath = 1
aio_kprocprio = 39
aio_multitidsusp = 1
aio_sample_rate = 5
aio_samples_per_cycle = 6
Bootet man also jetzt sein AIX 6 System, dann wird die AIO Kernel Extension geladen, und zwei Threads werden gestartet. Auf einem System, auf dem keine Applikation läuft, die AIO anfordert, ändert sich für den Rest der Laufzeit garnichts.
Fordert eine Applikation AIO an, so wird die entsprechende Zahl an AIO Servern nach dem Parameter aio_minserver (pro CPU) gestartet. Diese Server laufen auch dann weiter, wenn kein AIO mehr angefordert wird. Steigt die Last, so werden nach einander mehr AIO Server gestartet, bis der Parameter aio_maxservers (wieder pro CPU) erreicht ist. Ein AIO Server, der nichts mehr zu tun hat, wird nach dem Timeout in Sekunden (Parameter aio_server_inactivity) wieder abgeschaltet.
[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]
Copyright 2001-2021 by Orm Hager - Es gilt die GPL