orm@doc-tcpip.org

Erstellt: März 2006 - Letzte Modifikation: Januar 2009

[ Main | Local ]


Basics zum Asynchronen IO bei AIX


Asynchroner IO

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.

AIX 5 - Praktisches

Installiert sein muß folgendes Paket: bos.rte.aio

Das Device sieht man mit

lsdev -Cc aio
lsdev -Cc posix_aio
Diese Devices müssen "available" sein.

Wieviel AIO Server laufen auf meinem System?

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.

Wieviele AIO Server brauche ich?

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:

Asynchroner IO hat liefert Funktionen:

  1. Async. IO großer Files
  2. IO blockt keine Prozesse
  3. Ende des IO wird angezeigt
  4. IO Anforderungen können abgebrochen werden

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.

Tuning Parameter für AIO

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:

AIX 6 - Praktisches

Installiert sein muß folgendes Paket: bos.rte.aio

Die wichtigen Unterschiede bzw. Neuerungen:

Tuning Parameter für AIO in AIX 6

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.


[ Main | Local ]

[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | SMTP | Tracing | GPS ]

Copyright 2001-2014 by Orm Hager - Es gilt die GPL
Feedback bitte an: Orm Hager (orm@doc-tcpip.org )