Database Reference
In-Depth Information
size=1024m
bs=8k
directory=/u01/fio/data
ioengine=sync
iodepth=8
direct=1
invalidate=1
ioscheduler=noop
In plain English, the job named “random-read-sync” will use the random-read workload, creates a file of 1 GB
in size in the directory /u01/fio/data/ , and uses a block size of 8 kb, which matches Oracle's standard database
block size. A maximum of 8 outstanding I/O requests are allowed, and the Linux I/O scheduler to be used is the noop
scheduler since the storage in this case is non-rotational. The use of direct I/O is also requested, and the page cache
is invalidated first to avoid file system buffer hits for consistency with the other scripts in the test harness—direct I/O
will bypass with buffer cache anyway, so strictly speaking, the directive is redundant.
Linux can use different ways to submit I/O to the storage subsystem—synchronous and asynchronous.
Synchronous I/O is also referred to as blocking I/O, since the caller has to wait for the request to finish. Oracle
will always use synchronous I/O for single block reads such as index lookups. This is true, for example, even when
asynchronous I/O is enabled. The overhead of setting up an asynchronous request is probably not worth it for a single
block read.
There are situations wherein synchronous processing of I/O requests does not scale well enough. System
designers therefore introduced asynchronous I/O. The name says it all: when you are asynchronously issuing I/O
requests, the requestor can continue with other tasks and will “reap” the outstanding I/O request later. This approach
greatly enhances concurrency but, at the same time, makes tracing a little more difficult. As you will also see, the
latency of individual I/O requests increases with a larger queue depth. Asynchronous I/O is available on Oracle Linux
with the libaio package.
Another I/O variant is called direct I/O, which instructs a process to bypass the file system cache. The classic
UNIX file system buffer cache is known as the page cache in Linux. This area of memory is the reason why users do
not see free memory in Linux. Those portions of memory that are not needed by applications will be used for the page
cache instead.
Unless instructed otherwise, the kernel will cache information read from disk in said page cache. This cache is
not dedicated to a single process allowing other processes to benefit from it as well. The page cache is a great concept
for the many Linux applications but not necessarily beneficial for the Oracle database. Why not? Remember from
the preceding introduction that the result of regular file I/O is stored in the page cache in addition to being copied to
the user process's buffers. This is wasteful in the context of Oracle since Oracle already employs its own buffer cache
for data read from disk. The good intention of a file-system page cache is not needed for the Oracle database since it
already has its own cache to counter the relatively slow disk I/O operations.
There are cases in which enabling direct I/O causes performance problems, but those can easily be trapped in
test and development environments. However, using direct I/O allows the performance analyst to get more accurate
information from performance pages in Oracle. If you see a 1 ms response time from the storage array, you cannot be
sure if that is a great response time from the array or rather a cached block from the operating system. If possible, you
should consider enabling direct I/O after ensuring that it does not cause performance problems.
To demonstrate the difference between synchronous and asynchronous I/O, consider the following job file for
asynchronous I/O.
[oracle@server1 fio-2.1]$ cat rand-read-async.fio
[random-read-async]
rw=randread
size=1024m
bs=8k
directory=/u01/fio/data
Search WWH ::




Custom Search