Re: Checkpoint less frequently

On Thursday, February 20, 2003, at 04:37 PM, Branko Èibej wrote:

> Thanks, Brandon, this is a very good analysis. And it confirms my
> suspicions that we're using _way_ too many transactions, and issuing
> far
> too many txn_checkpoint calls.
>
> I think *the* major task for 0.19 is:
>
> * Stop creating transactions for read-only requests, and use
> ordinary locks instead.

Would this stop the log files growing on read-only requests?

% ls -l repos/db/log.*
-rw-r--r-- 1 willu staff 81442 Feb 20 21:12 repos/db/log.0000000001
% svn up wc
At revision 1.
% ls -l repos/db/log.*
-rw-r--r-- 1 willu staff 86589 Feb 20 21:12 repos/db/log.0000000001
% svn up wc
At revision 1.
% ls -l repos/db/log.*
-rw-r--r-- 1 willu staff 89135 Feb 20 21:13 repos/db/log.0000000001

Here it doesn't grow much, and so it isn't a major problem, but if it
were to go away I wouldn't mind. :)

> * Reduce the number of txn_checkpoint calls in our code, or even
> eliminate them completely.
>
> Before amyone starts wondering if I'm off my rocker, consider this: you
> only really need a txn_checkpoint when youre doing a hot backup of the
> database, or removing old log files. Therefore, checkpoints should be
> issued by the backup/cleanup scripts, definitely not in the critical
> path.

Reading http://www.sleepycat.com/docs/ref/transapp/checkpoint.html

it looks like the database is safe with less frequent checkpointing.
(checkpointing just syncs the database files. The log files are
already on disk.) Note that sleepycat mention checkpointing every 60
seconds, and "Because checkpoints can be quite expensive, choosing how
often to perform a checkpoint is a common tuning parameter for Berkeley
DB applications."

later,

Will :-}

--
Dr William Uther                            National ICT Australia
Phone: +61 2 9385 6926             School of Computer Science and 
Engineering
Email: willu@cse.unsw.edu.au             University of New South Wales
Jabber: willu@jabber.cse.unsw.edu.au          Sydney, Australia
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org