|Pros and Cons of Using Direct I/O for Databases [ID 1005087.1]|
Applies to:Solaris x64/x86 Operating System - Version: 8 6/00 U1 and later [Release: 8.0 and later ]
Solaris SPARC Operating System - Version: 8.0 and later [Release: 8.0 and later]
Oracle Solaris Express - Version: 2010.11 and later [Release: 11.0 and later]
NOTE: mmaped pages with write permission which have been modified are also flushed. For details on how the page cache is managed by Solaris, see Document 1003383.1 Understanding Cyclic Caching and Page Cache on Solaris 8 and Above.
Direct I/O is a filesystem feature that can be enabled via the forcedirectio mount option or within an application for a single file by calling directio(). Direct I/O offers several benefits:
There are some drawbacks to direct I/O that should be considered when
deciding whether to use it or not:
filesystemio_options=asynch (Enable asynchronous I/O only)
filesystemio_options=directIO (Enable direct I/O on all Oracle files)
filesystemio_options=setall (Enable asynchronous I/O and direct I/O on Oracle files)
NOTE: When enabling direct I/O in Oracle it is not needed to use filesystem direct mount option.
* lreads: logical reads to the UFS via directio * lwrites: logical writes to the UFS via directio * preads: physical reads to media * pwrites: physical writes to media * Krd: kilobytes read * Kwr: kilobytes written * nflush: number of cached pages flushed * holdrds: number of times the read was a "hole" in the file.
Anon 185051 1445 2%
Exec and libs 11894 92 0%
*Page cache 922689 7208 11% <
Free (cachelist) 1121939 8765 14%
Free (freelist) 5358354 41862 66%
Total 8062293 62986
Solaris 8 and below can use prtmem utility part of memtool package. Tool is available for download
prtmem (summary of where the system memory is used)
Total memory: 180 Megabytes
Kernel Memory: 30 Megabytes
Application memory: 82 Megabytes
Executable memory: 38 Megabytes
Buffercache memory: 22 Megabytes
Free memory: 5 Megabytes
(get_reclaim + get_use) / getmapThese may be obtained at set intervals via kstat unix:0:segmap:get\* 1. Another interesting measure is the rate of increase (the difference between 2 successive sets of data from the kstat command) of:
getmap - (get_reclaim + get_use)which is the number pages per second which are missing in segmap. This is a method of measuring whether tuning segmap_percent is helping segmap thrashing. If this number is small, no benefit should be expected from increasing 'segmap_percent'' in the first place.
We can associate an approximately 20% increase in performance on those pages if and only if we manage to keep them in segmap by increasing segmap_percent. There is no guarantee that increasing the size of segmap will cause the rate of segmap misses to go down-it is workload dependent. For example, if the number increases by 1000 pages per second; then that corresponds to 1000*8KB pages or 8MB/sec of I/O that may improve performance by 20% if increasing segmap_percent causes the data to stay mapped in segmap.
To discuss this information further with Oracle experts and industry peers, we encourage you to review, join or start a discussion in the My Oracle Support Community, Oracle Solaris Kernel Community.