Gecko [ 122.154.134.11 ]

Name	Size	Permission
admin.html	3.28 KB	-rw-r--r--
app.html	16.29 KB	-rw-r--r--
archival.html	9.52 KB	-rw-r--r--
atomicity.html	4.19 KB	-rw-r--r--
checkpoint.html	4.7 KB	-rw-r--r--
cursor.html	4.99 KB	-rw-r--r--
data_open.html	5.89 KB	-rw-r--r--
deadlock.html	5.78 KB	-rw-r--r--
env_open.html	6.53 KB	-rw-r--r--
fail.html	4.98 KB	-rw-r--r--
faq.html	7.8 KB	-rw-r--r--
filesys.html	4.22 KB	-rw-r--r--
hotfail.html	5.51 KB	-rw-r--r--
inc.html	6.1 KB	-rw-r--r--
intro.html	2.72 KB	-rw-r--r--
logfile.html	3.57 KB	-rw-r--r--
nested.html	4.19 KB	-rw-r--r--
put.html	10.51 KB	-rw-r--r--
read.html	7.93 KB	-rw-r--r--
reclimit.html	9.7 KB	-rw-r--r--
recovery.html	6.42 KB	-rw-r--r--
term.html	4.09 KB	-rw-r--r--
throughput.html	7.14 KB	-rw-r--r--
transapp.cs	10.34 KB	-rw-r--r--
tune.html	10.76 KB	-rw-r--r--
why.html	2.49 KB	-rw-r--r--
writetest.cs	2.32 KB	-rw-r--r--

Code Editor : tune.html

<html>
<head>
<title>Berkeley DB Reference Guide: Transaction tuning</title>
<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit.">
<meta name="keywords" content="embedded,database,programmatic,toolkit,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++">
</head>
<body bgcolor=white>
<a name="2"></a><a name="3"></a>
<table width="100%"><tr valign=top>
<td><dl><dt>Berkeley DB Reference Guide:<dd>Berkeley DB Transactional Data Store Applications</dl></td>
<td align=right><a href="../transapp/reclimit.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../transapp/throughput.html"><img src="../../images/next.gif" alt="Next"></a>
</td></tr></table>
Transaction tuning
There are a few different issues to consider when tuning the performance
of Berkeley DB transactional applications. First, you should review
<a href="../../ref/am_misc/tune.html">Access method tuning</a>, as the
tuning issues for access method applications are applicable to
transactional applications as well. The following are additional tuning
issues for Berkeley DB transactional applications:
 
access method<ul compact><li>Highly concurrent applications should use the Queue access method, where
possible, as it provides finer-granularity of locking than the other
access methods. Otherwise, applications usually see better concurrency
when using the Btree access method than when using either the Hash or
Recno access methods.</ul>
record numbers<ul compact><li>Using record numbers outside of the Queue access method will often slow
down concurrent applications as they limit the degree of concurrency
available in the database. Using the Recno access method, or the Btree
access method with retrieval by record number configured can slow
applications down.</ul>
Btree database size<ul compact><li>When using the Btree access method, applications supporting concurrent
access may see excessive numbers of deadlocks in small databases. There
are two different approaches to resolving this problem. First, as the
Btree access method uses page-level locking, decreasing the database
page size can result in fewer lock conflicts. Second, in the case of
databases that are cyclically growing and shrinking, turning off reverse
splits (with <a href="../../api_c/db_set_flags.html#DB_REVSPLITOFF">DB_REVSPLITOFF</a>) can leave the database with enough
pages that there will be fewer lock conflicts.</ul>
read locks<ul compact><li>Performing all read operations outside of transactions or at
<a href="../../ref/transapp/read.html">snapshot isolation</a> can often
significantly increase application throughput. In addition, limiting
the lifetime of non-transactional cursors will reduce the length of
times locks are held, thereby improving concurrency.</ul>
<a href="../../api_c/env_set_flags.html#DB_DIRECT_DB">DB_DIRECT_DB</a>, <a href="../../api_c/env_log_set_config.html#DB_LOG_DIRECT">DB_LOG_DIRECT</a><ul compact><li>Consider using the <a href="../../api_c/env_set_flags.html#DB_DIRECT_DB">DB_DIRECT_DB</a> and <a href="../../api_c/env_log_set_config.html#DB_LOG_DIRECT">DB_LOG_DIRECT</a> flags.
On some systems, avoiding caching in the operating system can improve
write throughput and allow the creation of larger Berkeley DB caches.</ul>
<a href="../../api_c/db_open.html#DB_READ_UNCOMMITTED">DB_READ_UNCOMMITTED</a>, <a href="../../api_c/db_cursor.html#DB_READ_COMMITTED">DB_READ_COMMITTED</a><ul compact><li>Consider decreasing the level of isolation of transaction using the
<a href="../../api_c/db_open.html#DB_READ_UNCOMMITTED">DB_READ_UNCOMMITTED</a> or <a href="../../api_c/db_cursor.html#DB_READ_COMMITTED">DB_READ_COMMITTED</a> flags for
transactions or cursors or the <a href="../../api_c/db_open.html#DB_READ_UNCOMMITTED">DB_READ_UNCOMMITTED</a> flag on
individual read operations. The <a href="../../api_c/db_cursor.html#DB_READ_COMMITTED">DB_READ_COMMITTED</a> flag will
release read locks on cursors as soon as the data page is nolonger
referenced. This is also called degree 2 isolation. This
will tend to block write operations for shorter periods for applications
that do not need to have repeatable reads for cursor operations.
The <a href="../../api_c/db_open.html#DB_READ_UNCOMMITTED">DB_READ_UNCOMMITTED</a> flag will allow read operations to
potentially return data which has been modified but not yet committed,
and can significantly increase application throughput in applications
that do not require data be guaranteed to be permanent in the database.
This is also called degree 1 isolation, or dirty
reads.</ul>
<a href="../../api_c/dbc_get.html#DB_RMW">DB_RMW</a><ul compact><li>If there are many deadlocks, consider using the <a href="../../api_c/dbc_get.html#DB_RMW">DB_RMW</a> flag to
immediate acquire write locks when reading data items that will
subsequently be modified. Although this flag may increase contention
(because write locks are held longer than they would otherwise be), it
may decrease the number of deadlocks that occur.</ul>
<a href="../../api_c/env_set_flags.html#DB_TXN_WRITE_NOSYNC">DB_TXN_WRITE_NOSYNC</a>, <a href="../../api_c/env_set_flags.html#DB_TXN_NOSYNC">DB_TXN_NOSYNC</a><ul compact><li>By default, transactional commit in Berkeley DB implies durability, that is,
all committed operations will be present in the database after recovery
from any application or system failure. For applications not requiring
that level of certainty, specifying the <a href="../../api_c/env_set_flags.html#DB_TXN_NOSYNC">DB_TXN_NOSYNC</a> flag will
often provide a significant performance improvement. In this case, the
database will still be fully recoverable, but some number of committed
transactions might be lost after application or system failure.</ul>
access databases in order<ul compact><li>When modifying multiple databases in a single transaction, always access
physical files and databases within physical files, in the same order
where possible. In addition, avoid returning to a physical file or
database, that is, avoid accessing a database, moving on to another
database and then returning to the first database. This can
significantly reduce the chance of deadlock between threads of
control.</ul>
large key/data items<ul compact><li>Transactional protections in Berkeley DB are guaranteed by before and after
physical image logging. This means applications modifying large
key/data items also write large log records, and, in the case of the
default transaction commit, threads of control must wait until those
log records have been flushed to disk. Applications supporting
concurrent access should try and keep key/data items small wherever
possible.</ul>
mutex selection<ul compact><li>During configuration, Berkeley DB selects a mutex implementation for the
architecture. Berkeley DB normally prefers blocking-mutex implementations over
non-blocking ones. For example, Berkeley DB will select POSIX pthread mutex
interfaces rather than assembly-code test-and-set spin mutexes because
pthread mutexes are usually more efficient and less likely to waste CPU
cycles spinning without getting any work accomplished.
For some applications and systems (generally highly concurrent
applications on large multiprocessor systems), Berkeley DB makes the wrong
choice. In some cases, better performance can be achieved by
configuring with the
<a href="../../ref/build_unix/conf.html#--with-mutex">--with-mutex</a>
argument and selecting a different mutex implementation than the one
selected by Berkeley DB. When a test-and-set spin mutex implementation is
selected, it may be useful to tune the number of spins made before
yielding the processor and sleeping. For more information, see the
<a href="../../api_c/mutex_set_tas_spins.html">DB_ENV-&gt;mutex_set_tas_spins</a> method.
Finally, Berkeley DB may put multiple mutexes on individual cache lines. When
tuning Berkeley DB for large multiprocessor systems, it may be useful to tune
mutex alignment using the
<a href="../../api_c/mutex_set_align.html">DB_ENV-&gt;mutex_set_align</a> method.</ul>
<a href="../../ref/build_unix/conf.html#--enable-posixmutexes">--enable-posixmutexes</a><ul compact><li>By default, the Berkeley DB library will only select the POSIX pthread mutex
implementation if it supports mutexes shared between multiple processes.
If your application does not share its database environment between
processes and your system's POSIX mutex support was not selected because
it did not support inter-process mutexes, you may be able to increase
performance and transactional throughput by configuring with the
<a href="../../ref/build_unix/conf.html#--enable-posixmutexes">--enable-posixmutexes</a> argument.</ul>
log buffer size<ul compact><li>Berkeley DB internally maintains a buffer of log writes. The buffer is
written to disk at transaction commit, by default, or, whenever it
is filled. If it is consistently being filled before transaction
commit, it will be written multiple times per transaction, costing
application performance. In these cases, increasing the size of the
log buffer can increase application throughput.</ul>
log file location<ul compact><li>If the database environment's log files are on the same disk as the
databases, the disk arms will have to seek back-and-forth between the
two. Placing the log files and the databases on different disk arms
can often increase application throughput.</ul>
trickle write<ul compact><li>In some applications, the cache is sufficiently active and dirty that
readers frequently need to write a dirty page in order to have space in
which to read a new page from the backing database file. You can use
the <a href="../../utility/db_stat.html">db_stat</a> utility (or the statistics returned by the
<a href="../../api_c/memp_stat.html">DB_ENV-&gt;memp_stat</a> method) to see how often this is happening in your
application's cache. In this case, using a separate thread of control
and the <a href="../../api_c/memp_trickle.html">DB_ENV-&gt;memp_trickle</a> method to trickle-write pages can often increase
the overall throughput of the application.</ul>
 
<table width="100%"><tr><td> </td><td align=right><a href="../transapp/reclimit.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../transapp/throughput.html"><img src="../../images/next.gif" alt="Next"></a>
</td></tr></table>
Copyright (c) 1996,2008 Oracle. All rights reserved.
</body>
</html>

${this.title}

Code Editor : tune.html