[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Transcript of chat between me and Sleeepycat

From: Brandon Ehle <azverkan_at_yahoo.com>
Date: 2003-02-20 22:13:00 CET

> Pretty much every svn operation touches the database in some way or
> another. Even an svn update when nothing has changed in either your
> working copy or the repository, so every operation will put the
> repository in a state where txn_checkpoint() has something to do.
> Therefore, txn_checkpoint() will get run after every single operation
> (in ra_dav mode this includes every PUT).

Why is subversion calling txn_checkpoint after every operation?
Performing checkpoints is necessary for two reasons: First, you
can remove the Berkeley DB log files from your system only after
a checkpoint. Second, the frequency of your checkpoints is
inversely proportional to the amount of time it takes to run
database recovery after a system or application failure.

I would expect an application to run checkpoint every 60 seconds
or so, at most. On a reasonably fast and stable server, doing
a checkpoint every 5-10 minutes would not be unreasonable.

Checkpoint is a heavy-weight operation, flushing all of the
dirty pages from the cache. In Berkeley DB releases before
4.1.XX that involves a long time under a single giant lock,
so if you're using a 4.0.XX or earlier release, it's going to
be even worse than if you're using the current release.

> Normally this isn't too bad, but as your repository grows, the
> checkpoint times will get larger and larger and eventually you could
> get to the point where my 15GB repository is at and a txn_checkpoint()
> takes 5 minutes or more.

The cost of a checkpoint is related to the size of your cache.
It is entirely unrelated to the size of the databases.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 20 22:12:17 2003

This is an archived mail posted to the Subversion Dev mailing list.