Question: What is
asynchronous I/O and how is asynchronous I/O different from standard
I/O?
Answer: In a nutshell,
asynchronous I/O is where the backend I/O subsystem (e.g. a
storage array) "acknowledges" that a write has been completed
while it is still waiting for a permanent write in the storage
array. This is called a "false ack",
the way that Oracle can perform high volumes of writes when
working with a vendor storage array.
When a system process attempts to read or write using the
normal synchronous read() or write() system calls, then it must
wait until the physical I/O is completed. Once the success or
failure of the read/write operation is known, the process finishes
the task. During this time, the execution of the process is
blocked while it waits for the results of the system call. This is
synchronous or blocking I/O.
However, the desired method is
Asynchronous I/O which indicates that it is a Non-blocking I/O. If
the process instead uses the asynchronous aio_read() or aio_write()
system calls, then the system call will return immediately once the
I/O request has been passed down to the hardware or queued in the
operating system, typically before the physical I/O operation has
even begun. It can continue executing and then receive the results
of the I/O operation later, once they are available. Thus it is
asynchronous or non-blocking I/O.
Asynchronous I/O enables write intensive
processes like Oracle's DBWn to make full use of the I/O bandwidth
of the hardware, by queuing I/O requests to distinct devices in
quick succession so that they can be processed largely in
parallel. Asynchronous I/O also allows processes performing
compute intensive operations like sorts to pre-fetch data from
disk before it is required so that the I/O and computation can
occur in parallel.
The performance of asynchronous
I/O is depends much on if the kernelized asynchronous I/O or
threaded asynchronous I/O is used.
* For kernelized asynchronous
I/O, the kernel allocates an asynchronous I/O request data structure
and calls an entry point in the device driver to set up the
asynchronous I/O request. The device driver then queues the physical
I/O operation and returns control to the calling process. When the
physical I/O operation has completed, the hardware generates an
interrupt to a CPU. The CPU switches into interrupt service context
and calls the device driver's interrupt service routine to update
the asynchronous I/O request data structure and possibly to signal
the calling process with SIGIO.
* The threaded implementation of
asynchronous I/O uses the kernel's light-weight process
functionality to simulate asynchronous I/O by performing multiple
synchronous I/O requests in distinct threads. This achieves I/O
parallelism at the expense of additional CPU usage associated with
thread creation and extra context switching overheads. If threaded
asynchronous I/O is used very intensively, these costs can add as
much as 5% to system CPU usage. For this reason using kernelized
asynchronous I/O is a preferred method.
Kernelized Asynchronous I/O,
popularly known as KIO, is only available if the underlying file
system uses Oracle Disk Manager (ODM) API, Veritas Quick I/O, or a
similar product that routes the I/O via a pseudo device driver that
can serve as the locus for asynchronous I/O request completion. Also
KIO is available if using raw partitions. Many operating systems
also require special configuration of device files, device drivers
and kernel parameters to enable and tune kernelized asynchronous
I/O. It is definitely a complex configuration to achieve
Asynchronous I/O. The best news is that the KIO is available with
the ASM files automatically.
and include the URL for the page.
