12.5. Verifying Asynchronous I/O Usage

To verify whether $ORACLE_HOME/bin/oracle was linked with asynchronous I/O, you can use the Linux commands ldd and nm.
In the following example, $ORACLE_HOME/bin/oracle was relinked with asynchronous I/O:
$ ldd $ORACLE_HOME/bin/oracle | grep libaio
	libaio.so.1 => /usr/lib/libaio.so.1 (0x0093d000)
$ nm $ORACLE_HOME/bin/oracle | grep io_getevent
	w io_getevents@@LIBAIO_0.1
$
In the following example, $ORACLE_HOME/bin/oracle has NOT been relinked with asynchronous I/O:
$ ldd $ORACLE_HOME/bin/oracle | grep libaio
$ nm $ORACLE_HOME/bin/oracle | grep io_getevent
	w io_getevents
$
If $ORACLE_HOME/bin/oracle is relinked with asynchronous I/O it does not necessarily mean that Oracle is really using it. You also have to ensure that Oracle is configured to use asynchronous I/O calls, see Enabling Asynchronous I/O Support.
To verify whether Oracle is making asynchronous I/O calls, you can take a look at the /proc/slabinfo file assuming there are no other applications performing asynchronous I/O calls on the system. This file shows kernel slab cache information in real time.
On a Red Hat Enterprise Linux 3 system where Oracle does not make asynchronous I/O calls, the output looks like this:
$ egrep "kioctx|kiocb" /proc/slabinfo
kioctx                 0      0    128    0    0    1 : 1008  252
kiocb                  0      0    128    0    0    1 : 1008  252
$
Once Oracle makes asynchronous I/O calls, the output on a Red Hat Enterprise Linux 3 system will look like this:
$ egrep "kioctx|kiocb" /proc/slabinfo
kioctx               690    690    128   23   23    1 : 1008  252
kiocb              58446  65160    128 1971 2172    1 : 1008  252
$
The numbers in red (number of active objects) show whether Oracle makes asynchronous I/O calls. The output will look a little bit different in Red Hat Enterprise Linux 4 and 5. However, the numbers in red will show same behavior in Red Hat Enterprise Linux 3 and Red Hat Enterprise Linux 4 and 5. The first column displays the cache names kioctx and kiocb. The second column shows the number of active objects currently in use. And the third column shows how many objects are available in total, used and unused.
To see kernel slab cache information in real time, you can also use the slabtop command:
$ slabtop
Active / Total Objects (% used)    : 293568 / 567030 (51.8%)
Active / Total Slabs (% used)      : 36283 / 36283 (100.0%)
Active / Total Caches (% used)     : 88 / 125 (70.4%)
Active / Total Size (% used)       : 81285.56K / 132176.36K (61.5%)
Minimum / Average / Maximum Object : 0.01K / 0.23K / 128.00K

OBJS    ACTIVE  USE    OBJ SIZE  SLABS OBJ/SLAB CACHE   SIZE NAME
178684  78396   43%    0.12K     5764    31     23056K  size-128
127632  36292   28%    0.16K     5318    24     21272K  dentry_cache
102815  74009   71%    0.69K     20563   5      82252K  ext3_inode_cache
71775   32434   45%    0.05K     957     75     3828K   buffer_head
19460   15050   77%    0.27K     1390    14     5560K   radix_tree_node
13090   13015   99%    0.03K     110     119    440K    avtab_node
12495   11956   95%    0.03K     105     119    420K    size-32
...
Slab caches are a special memory pool in the kernel for adding and removing objects, such as data structures or data buffers, of the same size. Its a cache for commonly used objects where the kernel does not have to re-allocate and initialize the object each time it is being reused, and free the object each time it is being destroyed. The slab allocator scheme basically prevents memory fragmentation and it prevents the kernel from spending too much time allocating, initializing, and freeing the same objects.