diff options
Diffstat (limited to 'docs/programmer_reference/transapp_tune.html')
| -rw-r--r-- | docs/programmer_reference/transapp_tune.html | 328 |
1 files changed, 196 insertions, 132 deletions
diff --git a/docs/programmer_reference/transapp_tune.html b/docs/programmer_reference/transapp_tune.html index 7bdc1049..7f8dfd51 100644 --- a/docs/programmer_reference/transapp_tune.html +++ b/docs/programmer_reference/transapp_tune.html @@ -14,7 +14,7 @@ <body> <div xmlns="" class="navheader"> <div class="libver"> - <p>Library Version 11.2.5.3</p> + <p>Library Version 12.1.6.1</p> </div> <table width="100%" summary="Navigation header"> <tr> @@ -22,9 +22,7 @@ </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> + <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> @@ -38,192 +36,257 @@ </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> + <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> + <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> + <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> + <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> + <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> + 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/dbcget.html#dbcget_DB_READ_COMMITTED" class="olink">DB_READ_COMMITTED</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> + 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> + <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> + <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> + <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> + <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> + 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> - 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> + 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. This may be particularly + beneficial for systems containing several + hyperthreaded processor cores. 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> + <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> + <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> + <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> + <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> @@ -242,7 +305,8 @@ the overall throughput of the application.</dd> <td width="20%" align="center"> <a accesskey="h" href="index.html">Home</a> </td> - <td width="40%" align="right" valign="top"> Transaction throughput</td> + <td width="40%" align="right" valign="top"> Transaction + throughput</td> </tr> </table> </div> |