Optimizing Server Settings - High Performance MySQL - page 363

You generally need a RAID card with a write cache set to a write-back policy if you
use O_DIRECT , because that's typically the only thing that keeps performance good.
Using O_DIRECT when there is no buffer between InnoDB and the actual storage
device, such as when you have no write cache on your RAID card, can cause per-
formance to degrade greatly. This is a bit less of a problem nowadays with multiple
write threads (and native asynchronous I/O introduced in MySQL 5.5), but it's
still the case in general.
This setting can cause the server's warmup time to increase significantly, especially
if the operating system's cache is very large. It can also make a small buffer pool
(e.g., a buffer pool of the default size) much slower than buffered I/O would. This
is because the operating system won't “help out” by keeping more of the data in
its own cache. If the desired data isn't in the buffer pool, InnoDB will have to read
it directly from disk.
This setting does not impose any extra penalty on the use of innodb_
file_per_table . However, the reverse can be true: if you do not use innodb_file_
per_table , you can suffer from some serialization of I/O when you use O_DIRECT .
This happens because some filesystems (including all of Linux's ext filesystems)
have a per-inode mutex. When you use O_DIRECT with such filesystems, you really
need innodb_file_per_table to be enabled. We delve more into filesystems in the
next chapter.
ALL_O_DIRECT
This option is available in Percona Server and MariaDB. It lets the server open the
log files, not just the data files, in the same way that standard MySQL opens the
data files.
O_DSYNC
This option sets the O_SYNC flag on the open() call for the log files. It makes all writes
synchronous—in other words, writes do not return until the data is written to
disk. This option does not affect the data files.
The difference between the O_SYNC flag and the O_DIRECT flag is that O_SYNC doesn't
disable caching at the operating system level. Therefore, it doesn't avoid double
buffering, and it doesn't make writes go directly to disk. With O_SYNC , writes modify
the data in the cache, and then it is sent to the disk.
While synchronous writes with O_SYNC might sound very similar to what fsync()
does, the two can be implemented very differently on both the operating system
and the hardware level. When the O_SYNC flag is used, the operating system might
pass a “use synchronous I/O” flag down to the hardware level, telling the device
not to use caches. On the other hand, fsync() tells the operating system to flush
modified buffers to the device, followed by an instruction for the device to flush
its own caches, if applicable, so it is certain that the data has been recorded on the
physical media. Another difference is that with O_SYNC , every write() or pwrite()
operation syncs data to disk before it finishes, blocking the calling process. In con-
trast, writing without the O_SYNC flag and then calling fsync() allows writes to