db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Øystein Grøvlen <Oystein.Grov...@Sun.COM>
Subject Re: Discussion of incremental checkpointing----Added some new content
Date Tue, 14 Feb 2006 03:27:31 GMT
Suresh Thalamati wrote:
> I agree, it will be nice to have checkpoints(light checkpoint) that does 
> not need to flush whole cache to the disk, especially when the cache is 
> configured to be very large. I also remember reading about it long time 
> ago some where. I think the basic idea is to keep track of the highest 
> LSN of the pages that got flushed to the disk and at checkpoint flush 
> any pages with LSN lesser than are still in the cache, this might be 
> achieved by keeping first LSN that updated the page , in addition to the 
> last LSN that currently used to flush the log when page is written to 
> the disk. Main difference between the current check point and this one 
> will be REDO Low Water Mark can be long before the checkpoint log 
> record. In the worst case scenario it will be same as the current 
> checkpoint.

Correct, and that is why I think the checkpoint should make sure to 
write the oldest pages.  That way, you will advance the REDO Low Water Mark.

> 
> Changing the page writes to synhcronous using "rwd" is good idea when 
> cache is large. In small cache sizes like the default of 1000 pages ,
> it might be problem  because user request for a empty page is likely to 
> trigger foreground sync writes.
> 

The right way to avoid this is to make sure that the background writer 
is so efficient that this is a rare scenario.  In order to achieve this, 
one may need several threads to do background writing.  If one is still 
worried about the effects on user transactions, one could make the disk 
write asynchronous to the user threads by doing the writing in another 
thread, and allowing the cache to temporarily grow so that the user 
thread can immediately read in the requested page.  (This is basically 
what is done today except that one use memory in the file system buffer 
for the page to be written instead of on the Java heap.)

--
Øystein

Mime
View raw message