RE: Asynchronous I/O on Solaris

Veritas - Not sure how it's licensed, but I believe it's an add-on to VxFS

Shawn M Ferris
Oracle DBA - Time Warner Telecom

> -----Original Message-----
> From: Lewis, Ed [mailto:Ed_Lewis_at_PremierInc.com]
> Sent: Tuesday, November 14, 2000 5:50 AM
> To: Multiple recipients of list ORACLE-L
> Subject: RE: Asynchronous I/O on Solaris
>
>
> Steve,
> When you mention Quick I/O, is that
> a feature of Solaris, or the Veritas
> product ? Thanks for the info.
>
> -----Original Message-----
> Sent: Tuesday, November 14, 2000 1:00 AM
> To: Multiple recipients of list ORACLE-L
>
>
> Hi All,
>
> It seems that the issue of asynchronous I/O on Solaris is
> still alive and
> kicking. Here is an attempt to pull the threads together.
>
> Oracle 7 had an 'async_write' parameter that used to default
> to TRUE. If set
> to
> FALSE, Oracle would use the standard 'write()' system call to
> do synchronous
> writes. So DBWR for example would have to wait for each physical I/O
> operation
> to complete before it could do anything else. So if DBWR
> needed to write 1
> block
> to each of 10 disks, all those write operations would be done
> in series. The
> intent of the default use of asynchronous I/O was to allow
> multiple writes
> to
> distinct disks to be performed in parallel by a single process.
>
> Up to Solaris 2.3, there was only a threads based implementation of
> asynchronous
> I/O. For every concurrent asynchronous I/O operation, the 'aiowrite()'
> system
> call would allocate or spawn a light-weight process to
> perform an ordinary
> synchronous write. This achieved I/O parallelism at the expense of
> additional
> CPU usage associated with thread creation and extra context switching
> overheads.
> Under moderate to heavy write loads it was actually more
> efficient to set
> 'async_write' to FALSE and to configure a modest number of DBWR slave
> processes
> using the 'db_writers' parameter. The performance gain here
> was commonly of
> the
> order of 2% to 5%.
>
> Solaris 2.4 introduced kernelized asynchronous I/O (KAIO) for
> raw devices.
> This
> is an alternative implementation of the 'aiowrite()' system
> call that avoids
> the
> unwanted performance costs of the threads based
> implementation. Because KAIO
> only works for raw devices, the 'aiowrite()' system call was
> changed to use
> KAIO
> on raw devices and to use the threads based implementation
> for file system
> I/O.
>
> With the introduction of Quick I/O with Solaris 2.5.1, it
> became possible to
> use
> KAIO against file system based datafiles. Thus the
> 'aiowrite()' system call
> was
> changed to attempt to use KAIO even on file systems, and then
> to revert to
> threads based asynchronous I/O if that fails. This increased
> the overhead of
> asynchronous I/O even further, so that more sites needed to disable
> asynchronous
> I/O using Oracle parameters than before. From Oracle8 this is
> done using the
> 'disk_asynch_io' parameter, normally in conjunction with either the
> 'db_writer_processes' or 'dbwr_io_slaves' parameters.
>
> The situation was confused somewhat by bug 4222164 in Solaris
> 2.6, that
> affected
> patchsets below 105181-19 and greatly exaggerated the
> performance cost of
> the
> threads based implementation of asynchronous I/O. However,
> the basic problem
> of
> the performance overhead of file system based asynchronous I/O remains
> unchanged
> despite the resolution of this bug.
>
> Oracle have responded at 8.1 by avoiding the use of
> 'aiowrite()' for UFS
> based
> datafiles. That has confined the problem to VxFS based
> datafiles for which
> Quick
> I/O is not enabled -- still a large number of sites. A more
> general solution
> is
> promised with 8.1.7 in which Oracle will attempt to recognise
> whether KAIO
> is
> available for file system based datafiles, and decide
> dynamically whether to
> use
> 'aiowrite()' or not. There may also be a new '_filesystemio_options'
> parameter
> to override the default intelligence if necessary.
>
> @ Regards,
> @ Steve Adams
> @ http://www.ixora.com.au/
> @ http://www.christianity.net.au/
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Steve Adams
> INET: steve.adams_at_ixora.com.au
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Lewis, Ed
> INET: Ed_Lewis_at_PremierInc.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
Received on Tue Nov 14 2000 - 07:15:36 CST