Thanks for the forward, Brandon.
I think we basically knew this. I'm not sure why Subversion has the
frequent checkpointing right now; the reasons for that are lost in the
mists of history :-). We all agree it should be done less frequently,
the main question is whether to still invoke it from within the
Subversion server, or move it out to a separate script. Since
checkpointing is only about logfiles vs database files, it isn't (?)
ever a correctness issue (unless someone removes log files when they
shouldn't, of course).
The more complex question is whether we need to be creating BDB
transactions as often as we do, or whether we can get away with
locking -- or nothing at all -- under some circumstances.
Not proposing a specific action yet; still waiting to see what exactly
Brane had in mind re: locking vs transactions.
Brandon Ehle <email@example.com> writes:
> 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: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Feb 20 22:30:28 2003