Ce contenu n'est pas disponible dans la langue sélectionnée.
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.
