RE: excessive number of db writer

 >>>

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
>>>http://www.landsbanki.is/disclaimer
>>>--
>>>http://www.freelists.org/webpage/oracle-l
>>>
>>>
>>>

--
http://www.freelists.org/webpage/oracle-l