RE: dbwr_io_slaves usage on sigle cpu microsoft windows
- From: "Kevin Closson" <kevinc@xxxxxxxxxxxxx>
- To: "Jared Still" <jkstill@xxxxxxxxx>
- Date: Mon, 21 Aug 2006 16:53:25 -0700
> As Windows does asynch IO by default, there is
probably not too
much
benefit in setting IO slaves.
> ^^^^
> ...in fact, to the contrary...
> ...please explain
... db block buffer flushing through slaves is pretty clunky
considering you have OS Async, ODM and multiple database writers
options. With slaves, DBWR builds a batch and tasks a set of writers
who in turn loop through and perform synchronous I/Os of the buffers
they were tasked with flushing.
Until all the writes are done and the slaves report back, DBWR is
completely idle. So, a write batch operation is only as fast as the
slowest sub-set. Consider a batch that consists of, say, 128 buffers.
If you have 16 slaves, it might turn out that the slaves are all tasked
evenly so each "sub batch" would consist of 8 synchronous writes. If
those
take on average 10ms, and all the other slaves experience similar I/O
service times, the master DBWR will be waiting for 80ms...along with all
those foreground processes waiting in free buffer wait. With async, ODM
or multiple writers, each completed I/O request is followed with
LRU handling associated with freeing the buffer...so free buffer waiters
don't wait as long. With async, ODM and multiple writers, DBWR processes
also build their next batch while previous I/O is in flight. More
efficient...especially in systems suffering cache buffers chain latch
contention.
Slaves cause an inordinate amount of IPC overhead as well.
Old technology from a bygone day.
The Win32 API offers Oracle very good async I/O handling.
--
//www.freelists.org/webpage/oracle-l
Other related posts:
