Asynchronous disk I/O performance tuning

If an application does a synchronous I/O operation, it must wait for the I/O to complete. In contrast, asynchronous I/O operations run in the background and do not block user applications. This improves performance, because I/O operations and applications processing can run simultaneously. Many applications, such as databases and file servers, take advantage of the ability to overlap processing and I/O.

Applications can use the aio_read(), aio_write(), or lio_listio() subroutines (or their 64-bit counterparts) to perform asynchronous disk I/O. Control returns to the application from the subroutine as soon as the request has been queued. The application can then continue processing while the disk operation is being performed.

To manage asynchronous I/O, each asynchronous I/O request has a corresponding control block in the application's address space. This control block contains the control and status information for the request. It can be used again when the I/O operation is completed.

The user application can determine how to be notified when the I/O operation completes in the following ways:

• The application can poll the status of the I/O operation.
• The system can asynchronously notify the application when the I/O operation is done.
• The application can block until the I/O operation is complete.

Each I/O is handled by a single kernel process, or kproc, and typically the kproc cannot process any more requests from the queue until that I/O has completed. The default value of the minservers tunable is 3, and that of the maxservers tunable is 30. The maxservers value is the number of async I/O kprocs per processor. To obtain the maximum number of asynchronous I/O kprocs running on an AIX system, multiply the maxservers value with the number of currently running processors.

All of the AIO tunables have a current, default, minimum and maximum value that can be viewed with the ioo command. Only the current value can be changed with the ioo command. The other three values are fixed and are presented to inform the user of the bounds of the tunable. The current value of the tunable can be changed at any time and can be made persistent across operating system restarts. In systems that seldom run applications that use asynchronous I/O, the defaults are usually adequate.

It is important to note that both minservers and maxservers are per-processor tunables. Both of these tunables are dynamic, but changes to their values do not result in a synchronous change in the number of available servers in the system. If the value of minservers is increased, the actual number of servers rises directly proportional to the number of concurrent I/O requests. Once the new minservers value is reached, it becomes the new floor. Conversely, when minservers is decreased, the number of available servers naturally falls to that level as servers exit due to inactivity. If the number of async I/O requests is high, increase the maxservers value to approximately the number of simultaneous I/Os there might be. It is usually better to leave the minservers parameter at the default value because the AIO kernel extension will generate additional servers if needed.

By looking at the processor utilization of the AIO servers, if the utilization is evenly divided among all of them, that means that they're all being used; you may want to try increasing them in this case. To see the AIO servers by name, run the pstat -a command. Run the ps -k command to see the AIO servers as the name kproc.

For environments in which the performance of asynchronous disk I/O is critical and the volume of requests is high, but you do not have an approximate number of simultaneous I/Os, it is recommended that maxservers be set to at least 10 * (number of disks accessed asynchronously).

For more information about Asynchronous I/O tuning values, see Changing Tunable Values for Asynchronous I/O.