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
Date Fri, 17 Feb 2006 21:37:10 GMT
Dibyendu Majumdar wrote:

> I guess the main difference between ARIES and Derby's method is that in 
> ARIES, checkpoints happen independently of Buffer Writes. However, in 
> the end the amount of work done is the same, as the data pages must be 
> written out anyway.

I do not think it is necessarily true that amount of work will be the 
same.  Different ways of doing checkpointing may cause a page to be 
written for every update or for every tenth update.

> 1. Make checkpoints lightweight like ARIES? If so, this would require 
> major changes to recovery logic.

I think the main change would be that it need to be possible to start 
the redo activity from any position in the log, not only from the 
position of a checkpoint log record.

> 2. Optimize the IO during checkpoints? I guess if this is the goal, then 
> one should concentrate on improving the current IO logic - potentially 
> by ensuring that:
> a) IO is non-disruptive - ie  - pages are not locked out while they are 
> being written.
> b) IO is optimized - batch write consecutive pages, etc.
> c) Have multiple concurrent threads handle IO.
> However these changes are useful in large scale environments and will 
> actually have a negative impact on a small scale system. No point in 
> increasing IO if there is a single disk, for example.
> 3. Slow down the IO during checkpoints? I think this is what Mike wants 
> to do. As far as I know, increasing the time taken to perform a 
> checkpoint should have no adverse effect. For example, you could reduce 
> the sleep time between checkpoints but slow down the checkpoint itself. 
> This way you could keep the total number of pages written fairly 
> constant without causing peeks of IO.

I think the goal should be, as you state in 3, to spread the disk I/O 
evenly over time and avoid bursts of IO when checkpointing.


View raw message