Re: excessive number of db writer

  • From: "LS Cheng" <exriscer@xxxxxxxxx>
  • To: kevinc@xxxxxxxxxxxxx
  • Date: Wed, 6 Sep 2006 22:03:13 +0200

Hm after 13 messages no one actually pointed out the side effects? :-P

On 9/6/06, Kevin Closson <kevinc@xxxxxxxxxxxxx> wrote:

>>> >>> >>>Is it known what exactly is the difference between Oracle's >>>dbwr "master-slaves" and "mutiple dbwr"? As far as I >>>understand it is about making access to LRU *parallel* by >>>adding multiply LRU lists, isn't it?

the difference lies entirely in the fact that writer slaves
do nothing more than perform writes. They do not grab latches.
That is, writer slaves do not grab latches.

It is a poor-man's way to get quasi-asynchronous buffer flushing,
but it actually stinks a bit because the freeing activity by the
master is whole-parcel activity. So, if the master hands, say, 256
writes to each of two slaves, the master does not free the 512
buffers until ALL the 256 writes from each writer have completed
and the slaves posted back to the master. If the slaves use
synchronous I/O... uh, you know what I'm going to say ...

If they use async I/O, a sub-batch is only as fast as the slowest
write in the sub-batch. So, if one of the I/Os in one of the
256 sub-batches happens to take 50 milliseconds, but the other
255 took, on average, 8, the master does not get to free any
of those buffers for 50 milliseconds because the slave loop
keeps him there until all are done.  This model is really
inefficient from a processor cache basis. The bus traces always
look like a fresh road-kill when compared to single process
async I/O dbwr... especially when compined with an elegant
venctored semop so that a single system call can post
all the busy buffer waiters ... ahhh...port optimizations...
the good old days ...  gone with the wind (thanks linux).

>>>Fyrirvari/Disclaimer >>> >>>-- >>>// >>> >>> >>> -- //

Other related posts: