Re: aio on sun ufs problem
- From: "zhu chao" <chao_ping@xxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>, <k.sriramkumar@xxxxxxxxxxxxxxxxxx>
- Date: Thu, 3 Jun 2004 13:53:27 +0800
Hi,
I agree with you, though I do not find theory support(from official
unix vendor document).
Test shows only write can use the kaio os call. Read cannot. And in
most case, only dbwr/lgwr does the write, server process don't do
write(unless doing create table/index etc, which does not happen often in
production environment). So, the cost of thread management using light
weight process to simulate true aio , only exist for the dbwr/lgwr process.
And in most case ( I just guess), these two process just use a small percent
of the total CPU. So, even these two process does not CPU at all, we cannot
expect much CPU usage reduction.
I get the result from my last week's tuning effort. We migrated our
database on vxfs without qio to raw volume, hoping to see some CPU usage
reduction and IO wait drop. But things did not happen. Just no difference
from unix at all. (we already put the redo/undo on raw volume before the
migration).
Using raw io, there is no so- called "Double Buffering" cost. And
single file write lock contention. But in real life active OLTP production
database, we see no performance difference.
Regards
Zhu Chao.
----- Original Message -----
From: <k.sriramkumar@xxxxxxxxxxxxxxxxxx>
To: <oracle-l@xxxxxxxxxxxxx>
Sent: Thursday, June 03, 2004 12:46 PM
Subject: RE: aio on sun ufs problem
> Hi Zhu,
>
> My understanding is that... Oracle Server process reads always have to be
synchronous .Server Process will have to wait till the data is read and
returned. They can proceed with the next operation ONLY after they get the
data(Kind of a pipeline) . Asynchronous read would not be useful for these
processes.
>
> Best Regards
>
> Sriram Kumar
>
>
> -----Original Message-----
> From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of zhu chao
> Sent: Wednesday, May 05, 2004 10:49 AM
> To: oracle-l@xxxxxxxxxxxxx
> Subject: Re: aio on sun ufs problem
>
> That is the point. The cost and benefit of using lwp based aio on
> filesystem, is it worthy or not.
>
> I saw note saying the cost of thread management and context switch is
> big, using LWP based AIO. Does any has measured the cost?
> (http://www.ixora.com.au/q+a/0011/14171201.htm)
>
> Another question, does aio only means asynch write(non-blocking
write),
> is there concept like asynch read? I did a test doing a full table scan on
a
> table which is a raw device. The os is doing pread os call, not
> kaio(aioread...).
>
> If only write benefit from asynch IO, then only dbwr/lgwr will benefit
> from KAIO. So when dbwr and lwgr can catch up clean the dirty buffer,
> whether to using aio does not matters.As server process only does read on
> datafile, and server process used most of system resource on a big
> system.(server process does write only during direct read/write and
creating
> tablespace,as far as I know).
>
> Just some thought and questions about this topic.
>
> Regards
> Zhu Chao.
> ----- Original Message -----
> >
>
> > ---
> > Aio on solaris is enabled by default if you use disk_asynch_io =3D true.
=
> > You
> > will see a failed system call to kaio and then pread pwrite processes =
> > spawn
> > to simulate aio via light weight threaded processing.
> > You can verify this in the same way using truss against dbwr. I'm not =
> > sure
> > what -t does, but if you just truss on dbwr process you will see the
> > behavior. I personally feel that dbwr_io_slaves when weighed against =
> > these
> > facts are better suted at simulating aio than the light weight threaded
> > processes.
> > - David
>
> >
> >
>
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
> put 'unsubscribe' in the subject line.
> --
> Archives are at //www.freelists.org/archives/oracle-l/
> FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
> put 'unsubscribe' in the subject line.
> --
> Archives are at //www.freelists.org/archives/oracle-l/
> FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
>
>
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
