You are currently on IBM Systems Media’s archival website. Click here to view our new website.

AIX > Administrator > Performance

AIO: The Fast Path to Great Performance

AIO Performance

Most AIX administrators are familiar with the concept of asynchronous input and output (AIO). AIO is coded into many operating systems, including most UNIX and Windows versions. You don't hear much about AIO, I guess because it's been around for so long it's somewhat taken for granted. It lacks the appeal of a flashy GUI, blazing response times or massive amounts of memory. Rest assured though, without AIO, our world would be a much slower place.

AIO is an essential performance feature of AIX; it’s been incorporated into the operating system for decades and is one of the first tunables newbie administrators learn to adjust. But to really see how AIO works in AIX and why it's so important, we need to understand some concepts and terminology.

The Basics

Essentially, AIO is input and output (or read and write) processing that allows still other processing to commence before the first I/O has completed.

Say you have a database that has created two threads, each of which initiates some form of I/O activity in your system. In a system without AIO, the first thread would carry out its I/O while the second thread would be forced to wait in a queue. Only when the first thread’s I/O was complete could the second thread’s I/O run.

This is an example of synchronous I/O―though programmers typically refer to it as “blocking I/O.” Back in the dark ages of computing systems before multitasking became an essential programming feature, this was how I/O was handled, and the systems that utilized it were s-l-o-w. Not only did I/O processing occur at a glacial pace, the net result was that most system resources―disk, CPU, memory and network―were idle the majority of the time. Think about it: If system function must be held up while your database does a simple read or write, and you’re doing thousands of those reads and writes, most of your time is going to be spent transitioning and readying the system to do the next I/O (and the next…). At a time when memory and CPUs were very expensive items, this I/O scheme did not produce the greatest bang for the IT investment dollar.

Fortunately, somewhere along the way a truly brilliant programmer(s) came up with code that allowed that second database thread to initiate its own I/O operation before the first thread had completed its I/O. And as the concept and the code behind it evolved, it became possible for computing systems to carry out hundreds and even thousands of I/O operations simultaneously without holding up other processing. Broadly speaking, this is “asynchronous” operation, and when applied to storage (and networking, incidentally), we call it AIO.

An aside: AIX is a bit confusing with its storage acronyms. We have AIO, but we also have CIO and DIO. We even have an error condition called EIO. Understandably, this can confuse beginning admins. Ultimately, though, it's simple: AIO is an I/O method, while DIO (direct I/O) and CIO (concurrent I/O) are ways to mount filesystems. EIO, as I said, is an error.

Also, before we go any further, I need to talk about the elephant in the room: Unless your application code specifically takes advantage of AIO, you won’t be able to use this facility. These days, most major database vendors' products utilize AIO, including Oracle, DB2 and Cache. But with applications―particularly homegrown applications and those produced by small vendors―it's pretty much a crapshoot. To determine if an app does use AIO, just take an AIX kernel trace and examine the data. This is easy—plus it's the only way to tell on your own if you have both a database and your app installed in the same system. Suffice it to say that, when in doubt, it’s best to contact your application vendor and talk directly to the developers. First line support almost never has this information.

Fastpath and Slowpath AIO

So how is AIO implemented in AIX? There are two implementation methods: fastpath and slowpath. In fastpath AIO, asynchronous I/O is handled through adapter driver software and/or Logical Volume Manager (LVM) code. In slowpath AIO, a kernel thread that's inserted into the I/O stream carries out the operation. This illustrates the difference in naming. If you have an additional hop for your I/O request to get from point A to point B, it's going to be slower compared to the more direct route.

Fastpath and slowpath AIO can be enabled in your AIX system simultaneously. Which method you'll use depends on your application or database programming code. In early AIX versions, AIO fastpath had to be specifically enabled, but these days it’s on by default. And every version of AIX as far back as I can remember always configured some number of AIO kernel threads to handle slowpath AIO, and this hasn’t changed much in more than two decades. The upshot is you’ll be covered either way.

Of course, nothing in UNIX is ever as straightforward as it seems. When we utilize kernel threads to handle AIO in AIX, we need to remember that there are two types, and we must also know which type our application or database uses. The AIO kernel thread types are “legacy” and “POSIX.” While they're the same from a functional standpoint, they're implemented into code in slightly different ways. (For our purposes these differences are negligible and we needn’t spend time on them. But if you really want to know, it’s spelled out online in the IBM Knowledge Center. Don’t say I didn’t warn you: this material is migraine-inducing.)

Anyway, AIX provides the option to alter the quantity of each type of kernel thread. Each consumes some memory for its process environment―about 440K―so if you’re on a low-memory system, I wouldn’t configure thousands of them. So how many of these AIO kernel threads―commonly called AIO servers―will you need? As root at an AIX command prompt, have a look at the input and output options (IOO) with this command:

	ioo –FL | more

You’ll get this output:

NAME                      CUR    DEF    BOOT   MIN    MAX    UNIT           TYPE
aio_active                0             0                    boolean           S
aio_maxreqs               128K   128K   128K   4K     1M     numeric           D
aio_maxservers            30     30     30     1      20000  numeric           D
aio_minservers            3      3      3      0      20000  numeric           D
aio_server_inactivity     300    300    300    1      86400  seconds           D

Mark J. Ray has been working with AIX for 23 years, 18 of which have been spent in performance. His mission is to make the diagnosis and remediation of the most difficult and complex performance issues easy to understand and implement. Mark can be reached at

Like what you just read? To receive technical tips and articles directly in your inbox twice per month, sign up for the EXTRA e-newsletter here.



2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

Achieving a Resilient Data Center

Implement these techniques to improve data-center resiliency.


AIO: The Fast Path to Great Performance

AIX Enhancements -- Workload Partitioning

The most exciting POWER6 enhancement, live partition mobility, allows one to migrate a running LPAR to another physical box and is designed to move running partitions from one POWER6 processor-based server to another without any application downtime whatsoever.

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters