1
<!--$Id: tune.so,v 11.8 2001/04/04 22:32:29 bostic Exp $-->
2
<!--Copyright 1997-2001 by Sleepycat Software, Inc.-->
3
<!--All rights reserved.-->
6
<title>Berkeley DB Reference Guide: Transaction tuning</title>
7
<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit.">
8
<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,java,C,C++">
11
<a name="2"><!--meow--></a><a name="3"><!--meow--></a>
12
<table width="100%"><tr valign=top>
13
<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Berkeley DB Transactional Data Store Applications</dl></h3></td>
14
<td align=right><a href="../../ref/transapp/reclimit.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/transapp/throughput.html"><img src="../../images/next.gif" alt="Next"></a>
17
<h1 align=center>Transaction tuning</h1>
18
<p>There are a few different issues to consider when tuning the performance
19
of Berkeley DB transactional applications. First, you should review
20
<a href="../../ref/am_misc/tune.html">Access method tuning</a>, as the
21
tuning issues for access method applications are applicable to
22
transactional applications as well. The following are additional tuning
23
issues for Berkeley DB transactional applications:
25
<p><dt>access method<dd>Highly concurrent applications should use the Queue access method, where
26
possible, as it provides finer-granularity of locking than the other
27
access methods. Otherwise, applications usually see better concurrency
28
when using the Btree access method than when using either the Hash or
30
<p><dt>record numbers<dd>Using record numbers outside of the Queue access method will often slow
31
down concurrent applications as they limit the degree of concurrency
32
available in the database.
33
Using the Recno access method, or the Btree access
34
method with retrieval by record number configured can slow applications
36
<p><dt>Btree database size<dd>When using the Btree access method, applications supporting concurrent
37
access may see excessive numbers of deadlocks in small databases. There
38
are two different approaches to resolving this problem. First, as the
39
Btree access method uses page-level locking, decreasing the database
40
page size can result in fewer lock conflicts. Second, in the case of
41
databases that are cyclically growing and shrinking, turning off reverse
42
splits can leave the database with enough pages that there will be fewer
44
<p><dt>transactionally protected read operations<dd>Most applications do not need repeatable reads. Performing all read
45
operations outside of transactions can often significantly increase
46
application throughput. In addition, limiting the lifetime of
47
non-transactional cursors will reduce the length of times locks are
48
held, thereby improving concurrency.
49
<p><dt><a href="../../api_c/db_open.html#DB_DIRTY_READ">DB_DIRTY_READ</a><dd>Consider using the <a href="../../api_c/db_open.html#DB_DIRTY_READ">DB_DIRTY_READ</a> flag for transactions, cursors
50
or individual read operations. This flag allows read operations to
51
potentially return data which has been modified but not yet committed,
52
and can significantly increase application throughput in applications
53
that do not require data be guaranteed to be permanent in the database.
54
<p><dt><a href="../../api_c/dbc_get.html#DB_RMW">DB_RMW</a><dd>Consider using the <a href="../../api_c/dbc_get.html#DB_RMW">DB_RMW</a> flag to immediate acquire write locks
55
when reading data items that will subsequently be modified. Although
56
this flag may increase contention (because write locks are held longer
57
than they would otherwise be), it may decrease the number of deadlocks
59
<p><dt><a href="../../api_c/env_open.html#DB_TXN_NOSYNC">DB_TXN_NOSYNC</a><dd>By default, transactional commit in Berkeley DB implies durability, that is,
60
all committed operations will be present in the database after
61
recovery from any application or system failure. For applications not
62
requiring that level of certainty, specifying the <a href="../../api_c/env_open.html#DB_TXN_NOSYNC">DB_TXN_NOSYNC</a>
63
flag will often provide a significant performance improvement. In this
64
case, the database will still be fully recoverable, but some number of
65
committed transactions might be lost after system failure.
66
<p><dt>large key/data items<dd>Transactional protections in Berkeley DB are guaranteed by before and after
67
physical image logging. This means applications modifying large
68
key/data items also write large log records, and, in the case of the
69
default transaction commit, threads of control must wait until those
70
log records have been flushed to disk. Applications supporting
71
concurrent access should try and keep key/data items small wherever
73
<p><dt>log buffer size<dd>Berkeley DB internally maintains a buffer of log writes. The buffer is
74
written to disk at transaction commit, by default, or, whenever it
75
is filled. If it is consistently being filled before transaction
76
commit, it will be written multiple times per transaction, costing
77
application performance. In these cases, increasing the size of the
78
log buffer can increase application throughput.
79
<p><dt>trickle write<dd>In some applications, the cache is sufficiently active and dirty that
80
readers frequently need to write a dirty page in order to have space in
81
which to read a new page from the backing database file. You can use
82
the <a href="../../utility/db_stat.html">db_stat</a> utility (or the statistics returned by the
83
<a href="../../api_c/memp_stat.html">memp_stat</a> function) to see how often this is happening in your
84
application's cache. In this case, using a separate thread of control
85
and the <a href="../../api_c/memp_trickle.html">memp_trickle</a> interface to trickle-write pages can often
86
increase the overall throughput of the application.
88
<table width="100%"><tr><td><br></td><td align=right><a href="../../ref/transapp/reclimit.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/transapp/throughput.html"><img src="../../images/next.gif" alt="Next"></a>
90
<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font>
added
removed
db/docs/ref/transapp/tune.html
