003 File Manager
Current Path:
/usr/local/share/doc/db5/programmer_reference
usr
/
local
/
share
/
doc
/
db5
/
programmer_reference
/
📁
..
📄
BDB_Prog_Reference.pdf
(1.9 MB)
📄
am.html
(13.27 KB)
📄
am_close.html
(4.17 KB)
📄
am_conf.html
(13.76 KB)
📄
am_conf_logrec.html
(7.32 KB)
📄
am_conf_select.html
(24.85 KB)
📄
am_cursor.html
(36.58 KB)
📄
am_delete.html
(2.95 KB)
📄
am_foreign.html
(9.84 KB)
📄
am_get.html
(4.07 KB)
📄
am_misc.html
(6.3 KB)
📄
am_misc_bulk.html
(17.31 KB)
📄
am_misc_db_sql.html
(4.79 KB)
📄
am_misc_dbsizes.html
(4.06 KB)
📄
am_misc_diskspace.html
(11.57 KB)
📄
am_misc_error.html
(4.83 KB)
📄
am_misc_faq.html
(10.34 KB)
📄
am_misc_partial.html
(7.81 KB)
📄
am_misc_perm.html
(4.19 KB)
📄
am_misc_stability.html
(4.82 KB)
📄
am_misc_struct.html
(5.06 KB)
📄
am_misc_tune.html
(9.91 KB)
📄
am_opensub.html
(7.84 KB)
📄
am_partition.html
(17.19 KB)
📄
am_put.html
(4.68 KB)
📄
am_second.html
(14.76 KB)
📄
am_stat.html
(3.11 KB)
📄
am_sync.html
(3.63 KB)
📄
am_truncate.html
(2.54 KB)
📄
am_upgrade.html
(4.72 KB)
📄
am_verify.html
(4.77 KB)
📄
apprec.html
(8.14 KB)
📄
apprec_auto.html
(12.16 KB)
📄
apprec_config.html
(10 KB)
📄
apprec_def.html
(9.13 KB)
📄
arch.html
(11.09 KB)
📄
arch_apis.html
(10.27 KB)
📄
arch_bigpic.gif
(2.53 KB)
📄
arch_progmodel.html
(3.1 KB)
📄
arch_script.html
(4.39 KB)
📄
arch_smallpic.gif
(1.58 KB)
📄
arch_utilities.html
(8 KB)
📄
bdb_usenix.pdf
(79.81 KB)
📄
bt_conf.html
(29.94 KB)
📄
cam.html
(11.77 KB)
📄
cam_app.html
(16.91 KB)
📄
cam_fail.html
(7.77 KB)
📄
ch13s02.html
(4.19 KB)
📄
csharp.html
(7.48 KB)
📄
dumpload.html
(5.42 KB)
📄
dumpload_format.html
(6.58 KB)
📄
dumpload_text.html
(3.39 KB)
📄
embedded.html
(31.62 KB)
📄
env.html
(7.43 KB)
📄
env_create.html
(10.06 KB)
📄
env_db_config.html
(4.21 KB)
📄
env_encrypt.html
(10.19 KB)
📄
env_error.html
(4.77 KB)
📄
env_faq.html
(5.54 KB)
📄
env_naming.html
(15.54 KB)
📄
env_open.html
(4.95 KB)
📄
env_region.html
(8.11 KB)
📄
env_remote.html
(5.28 KB)
📄
env_security.html
(5.64 KB)
📄
env_size.html
(8.11 KB)
📄
ext.html
(7.13 KB)
📄
ext_perl.html
(3.84 KB)
📄
ext_php.html
(5.47 KB)
📄
general_am_conf.html
(21.43 KB)
📄
gettingStarted.css
(1.13 KB)
📄
group_membership.html
(20.37 KB)
📄
hash_conf.html
(6.96 KB)
📄
hash_usenix.pdf
(256.14 KB)
📄
heap_conf.html
(4.14 KB)
📄
index.html
(77.48 KB)
📄
intro.html
(9.57 KB)
📄
intro_dbis.html
(15.02 KB)
📄
intro_dbisnot.html
(13.49 KB)
📄
intro_distrib.html
(2.92 KB)
📄
intro_need.html
(5.06 KB)
📄
intro_products.html
(14.3 KB)
📄
intro_terrain.html
(19.43 KB)
📄
intro_what.html
(4.94 KB)
📄
intro_where.html
(3.75 KB)
📄
java.html
(7.62 KB)
📄
java_compat.html
(2.57 KB)
📄
java_faq.html
(7.5 KB)
📄
java_program.html
(6.69 KB)
📄
libtp_usenix.pdf
(243.14 KB)
📄
lock.html
(11.29 KB)
📄
lock_am_conv.html
(10.62 KB)
📄
lock_cam_conv.html
(4.95 KB)
📄
lock_config.html
(4.67 KB)
📄
lock_dead.html
(7.25 KB)
📄
lock_deaddbg.html
(10.32 KB)
📄
lock_max.html
(11.04 KB)
📄
lock_nondb.html
(4.94 KB)
📄
lock_notxn.html
(4.55 KB)
📄
lock_page.html
(5.71 KB)
📄
lock_stdmode.html
(5.27 KB)
📄
lock_timeout.html
(6.16 KB)
📄
lock_twopl.html
(4.48 KB)
📄
log.html
(7.08 KB)
📄
log_config.html
(5.06 KB)
📄
log_limits.html
(4.24 KB)
📄
magic.s5.be.txt
(3.54 KB)
📄
magic.s5.le.txt
(3.56 KB)
📄
magic.txt
(1.98 KB)
📄
moreinfo.html
(7.45 KB)
📄
mp.html
(8.86 KB)
📄
mp_config.html
(6.08 KB)
📄
mp_warm.html
(13.45 KB)
📄
preface.html
(5.1 KB)
📄
program.html
(7.21 KB)
📄
program_cache.html
(3.3 KB)
📄
program_compatible.html
(3.66 KB)
📄
program_copy.html
(7.35 KB)
📄
program_environ.html
(3.58 KB)
📄
program_errorret.html
(10.38 KB)
📄
program_faq.html
(4.58 KB)
📄
program_mt.html
(7.54 KB)
📄
program_namespace.html
(5.66 KB)
📄
program_perfmon.html
(32.07 KB)
📄
program_ram.html
(12.58 KB)
📄
program_runtime.html
(7.09 KB)
📄
program_scope.html
(9.8 KB)
📄
refs.html
(11.84 KB)
📄
rep.html
(16.57 KB)
📄
rep_app.html
(9.75 KB)
📄
rep_base_meth.html
(8.59 KB)
📄
rep_bulk.html
(4.01 KB)
📄
rep_clock_skew.html
(5.38 KB)
📄
rep_comm.html
(11.28 KB)
📄
rep_elect.html
(13.17 KB)
📄
rep_ex.html
(9.64 KB)
📄
rep_ex_chan.html
(8.52 KB)
📄
rep_ex_comm.html
(7.58 KB)
📄
rep_ex_rq.html
(5.52 KB)
📄
rep_faq.html
(9.2 KB)
📄
rep_filename.html
(7.7 KB)
📄
rep_id.html
(4.76 KB)
📄
rep_init.html
(5.14 KB)
📄
rep_lease.html
(18.32 KB)
📄
rep_mastersync.html
(11.24 KB)
📄
rep_mgr_ack.html
(8.5 KB)
📄
rep_mgr_meth.html
(11.06 KB)
📄
rep_mgrmulti.html
(10.28 KB)
📄
rep_newsite.html
(5.29 KB)
📄
rep_partition.html
(9.21 KB)
📄
rep_pri.html
(3.64 KB)
📄
rep_replicate.html
(18.8 KB)
📄
rep_ryw.html
(9.82 KB)
📄
rep_trans.html
(21.58 KB)
📄
rep_twosite.html
(6.76 KB)
📄
repmgr_channels.html
(13.34 KB)
📄
rq_conf.html
(18.29 KB)
📄
second.javas
(3.87 KB)
📄
sequence.html
(4.43 KB)
📄
solaris.txt
(5.62 KB)
📄
stl.html
(16.28 KB)
📄
stl_complex_rw.html
(19.31 KB)
📄
stl_container_specific.html
(9.04 KB)
📄
stl_db_advanced_usage.html
(9.68 KB)
📄
stl_db_usage.html
(13.27 KB)
📄
stl_efficienct_use.html
(11.87 KB)
📄
stl_examples.html
(8.24 KB)
📄
stl_known_issues.html
(4.54 KB)
📄
stl_memory_mgmt.html
(9.22 KB)
📄
stl_misc.html
(8.22 KB)
📄
stl_mt_usage.html
(9.06 KB)
📄
stl_persistence.html
(14.74 KB)
📄
stl_primitive_rw.html
(8.18 KB)
📄
stl_txn_usage.html
(4.88 KB)
📄
stl_usecase.html
(3.67 KB)
📄
tcl.html
(7.88 KB)
📄
tcl_error.html
(5.2 KB)
📄
tcl_faq.html
(4.89 KB)
📄
tcl_program.html
(3.78 KB)
📄
tcl_using.html
(4.43 KB)
📄
transapp.cs
(10.34 KB)
📄
transapp.html
(8.55 KB)
📄
transapp_admin.html
(4.8 KB)
📄
transapp_app.html
(25.08 KB)
📄
transapp_archival.html
(15.5 KB)
📄
transapp_atomicity.html
(5.46 KB)
📄
transapp_checkpoint.html
(6.18 KB)
📄
transapp_cursor.html
(6.79 KB)
📄
transapp_data_open.html
(7.52 KB)
📄
transapp_deadlock.html
(7.35 KB)
📄
transapp_env_open.html
(8.39 KB)
📄
transapp_fail.html
(6.8 KB)
📄
transapp_faq.html
(11.26 KB)
📄
transapp_filesys.html
(5.89 KB)
📄
transapp_hotfail.html
(10.54 KB)
📄
transapp_inc.html
(8.09 KB)
📄
transapp_journal.html
(4.72 KB)
📄
transapp_logfile.html
(5.3 KB)
📄
transapp_nested.html
(5.42 KB)
📄
transapp_put.html
(12.47 KB)
📄
transapp_read.html
(9.9 KB)
📄
transapp_reclimit.html
(12.6 KB)
📄
transapp_recovery.html
(8.74 KB)
📄
transapp_term.html
(6.02 KB)
📄
transapp_throughput.html
(9.06 KB)
📄
transapp_tune.html
(13.99 KB)
📄
transapp_why.html
(3.94 KB)
📄
txn.html
(8.63 KB)
📄
txn_config.html
(4.5 KB)
📄
txn_limits.html
(5.77 KB)
📄
witold.html
(745 B)
📄
writetest.cs
(2.26 KB)
📄
xa.html
(6.69 KB)
📄
xa_build.html
(19.12 KB)
📄
xa_faq.html
(7.27 KB)
📄
xa_xa_config.html
(8.1 KB)
📄
xa_xa_intro.html
(4.46 KB)
📄
xa_xa_restrict.html
(6.02 KB)
Editing: transapp_tune.html
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <title>Transaction tuning</title> <link rel="stylesheet" href="gettingStarted.css" type="text/css" /> <meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /> <link rel="start" href="index.html" title="Berkeley DB Programmer's Reference Guide" /> <link rel="up" href="transapp.html" title="Chapter 11. Berkeley DB Transactional Data Store Applications" /> <link rel="prev" href="transapp_reclimit.html" title="Berkeley DB recoverability" /> <link rel="next" href="transapp_throughput.html" title="Transaction throughput" /> </head> <body> <div xmlns="" class="navheader"> <div class="libver"> <p>Library Version 11.2.5.3</p> </div> <table width="100%" summary="Navigation header"> <tr> <th colspan="3" align="center">Transaction tuning</th> </tr> <tr> <td width="20%" align="left"><a accesskey="p" href="transapp_reclimit.html">Prev</a> </td> <th width="60%" align="center">Chapter 11. Berkeley DB Transactional Data Store Applications </th> <td width="20%" align="right"> <a accesskey="n" href="transapp_throughput.html">Next</a></td> </tr> </table> <hr /> </div> <div class="sect1" lang="en" xml:lang="en"> <div class="titlepage"> <div> <div> <h2 class="title" style="clear: both"><a id="transapp_tune"></a>Transaction tuning</h2> </div> </div> </div> <p>There are a few different issues to consider when tuning the performance of Berkeley DB transactional applications. First, you should review <a class="xref" href="am_misc_tune.html" title="Access method tuning">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:</p> <div class="variablelist"> <dl> <dt> <span class="term">access method</span> </dt> <dd>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.</dd> <dt> <span class="term">record numbers</span> </dt> <dd>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.</dd> <dt> <span class="term">Btree database size</span> </dt> <dd>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_reference/C/dbset_flags.html#dbset_flags_DB_REVSPLITOFF" class="olink">DB_REVSPLITOFF</a>) can leave the database with enough pages that there will be fewer lock conflicts.</dd> <dt> <span class="term">read locks</span> </dt> <dd>Performing all read operations outside of transactions or at <a class="xref" href="transapp_read.html" title="Degrees of isolation">Degrees of 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.</dd> <dt> <span class="term"><a href="../api_reference/C/envset_flags.html#set_flags_DB_DIRECT_DB" class="olink">DB_DIRECT_DB</a>, <a href="../api_reference/C/envlog_set_config.html#log_set_config_DB_LOG_DIRECT" class="olink">DB_LOG_DIRECT</a></span> </dt> <dd> On some systems, avoiding caching in the operating system can improve write throughput and allow the creation of larger Berkeley DB caches.</dd> <dt> <span class="term"><a href="../api_reference/C/dbopen.html#dbopen_DB_READ_UNCOMMITTED" class="olink">DB_READ_UNCOMMITTED</a>, <a href="../api_reference/C/dbcget.html#dbcget_DB_READ_COMMITTED" class="olink">DB_READ_COMMITTED</a></span> </dt> <dd> <p> Consider decreasing the level of isolation of transaction using the <a href="../api_reference/C/dbopen.html#dbopen_DB_READ_UNCOMMITTED" class="olink">DB_READ_UNCOMMITTED</a>, or <a href="../api_reference/C/dbcget.html#dbcget_DB_READ_COMMITTED" class="olink">DB_READ_COMMITTED</a> flags for transactions or cursors or the <a href="../api_reference/C/dbopen.html#dbopen_DB_READ_UNCOMMITTED" class="olink">DB_READ_UNCOMMITTED</a> flag on individual read operations. The <a href="../api_reference/C/dbcget.html#dbcget_DB_READ_COMMITTED" class="olink">DB_READ_COMMITTED</a> flag will release read locks on cursors as soon as the data page is nolonger referenced. This is also called <span class="emphasis"><em> degree 2 isolation</em></span>. This will tend to block write operations for shorter periods for applications that do not need to have repeatable reads for cursor operations. </p> <p> The <a href="../api_reference/C/dbopen.html#dbopen_DB_READ_UNCOMMITTED" class="olink">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 <span class="emphasis"><em>degree 1 isolation</em></span>, or <span class="emphasis"><em>dirty reads</em></span>. </p> </dd> <dt> <span class="term"> <a href="../api_reference/C/dbcget.html#dbcget_DB_RMW" class="olink">DB_RMW</a> </span> </dt> <dd> If there are many deadlocks, consider using the <a href="../api_reference/C/dbcget.html#dbcget_DB_RMW" class="olink">DB_RMW</a> flag to immediately 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.</dd> <dt> <span class="term"><a href="../api_reference/C/envset_flags.html#set_flags_DB_TXN_WRITE_NOSYNC" class="olink">DB_TXN_WRITE_NOSYNC</a>, <a href="../api_reference/C/envset_flags.html#envset_flags_DB_TXN_NOSYNC" class="olink">DB_TXN_NOSYNC</a></span> </dt> <dd>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_reference/C/envset_flags.html#envset_flags_DB_TXN_NOSYNC" class="olink">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.</dd> <dt> <span class="term">access databases in order</span> </dt> <dd>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.</dd> <dt> <span class="term">large key/data items</span> </dt> <dd>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.</dd> <dt> <span class="term">mutex selection</span> </dt> <dd> <p> 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. </p> <p> 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="../installation/build_unix_conf.html#build_unix_conf.--with-mutex" class="olink">--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_reference/C/mutexset_tas_spins.html" class="olink">DB_ENV->mutex_set_tas_spins()</a> method. </p> <p> 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_reference/C/mutexset_align.html" class="olink">DB_ENV->mutex_set_align()</a> method. </p> </dd> <dt> <span class="term"> <a href="../installation/build_unix_conf.html#build_unix_conf.--enable-posixmutexes" class="olink">--enable-posix-mutexes</a> </span> </dt> <dd>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="../installation/build_unix_conf.html#build_unix_conf.--enable-posixmutexes" class="olink">--enable-posix-mutexes</a> argument.</dd> <dt> <span class="term">log buffer size</span> </dt> <dd>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.</dd> <dt> <span class="term">log file location</span> </dt> <dd>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.</dd> <dt> <span class="term">trickle write</span> </dt> <dd>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="../api_reference/C/db_stat.html" class="olink">db_stat</a> utility (or the statistics returned by the <a href="../api_reference/C/mempstat.html" class="olink">DB_ENV->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_reference/C/memptrickle.html" class="olink">DB_ENV->memp_trickle()</a> method to trickle-write pages can often increase the overall throughput of the application.</dd> </dl> </div> </div> <div class="navfooter"> <hr /> <table width="100%" summary="Navigation footer"> <tr> <td width="40%" align="left"><a accesskey="p" href="transapp_reclimit.html">Prev</a> </td> <td width="20%" align="center"> <a accesskey="u" href="transapp.html">Up</a> </td> <td width="40%" align="right"> <a accesskey="n" href="transapp_throughput.html">Next</a></td> </tr> <tr> <td width="40%" align="left" valign="top">Berkeley DB recoverability </td> <td width="20%" align="center"> <a accesskey="h" href="index.html">Home</a> </td> <td width="40%" align="right" valign="top"> Transaction throughput</td> </tr> </table> </div> </body> </html>
Upload File
Create Folder
