← Back to branch summary

~ubuntu-branches/ubuntu/maverick/evolution-data-server/maverick-proposed

« back to all changes in this revision

Viewing changes to libdb/docs/ref/lock/max.html

  • Committer: Bazaar Package Importer
  • Author(s): Didier Roche
  • Date: 2010-05-17 17:02:06 UTC
  • mfrom: (1.1.79 upstream) (1.6.12 experimental)
  • Revision ID: james.westby@ubuntu.com-20100517170206-4ufr52vwrhh26yh0
Tags: 2.30.1-1ubuntu1
https://launchpad.net/bugs/42199
https://launchpad.net/bugs/229669
https://launchpad.net/bugs/173703
https://launchpad.net/bugs/360344
https://launchpad.net/bugs/508494
* Merge from debian experimental. Remaining change:
  (LP: #42199, #229669, #173703, #360344, #508494)
  + debian/control:
    - add Vcs-Bzr tag
    - don't use libgnome
    - Use Breaks instead of Conflicts against evolution 2.25 and earlier.
  + debian/evolution-data-server.install,
    debian/patches/45_libcamel_providers_version.patch:
    - use the upstream versioning, not a Debian-specific one 
  + debian/libedata-book1.2-dev.install, debian/libebackend-1.2-dev.install,
    debian/libcamel1.2-dev.install, debian/libedataserverui1.2-dev.install:
    - install html documentation
  + debian/rules:
    - don't build documentation it's shipped with the tarball

Show diffs side-by-side

added added

removed removed

Lines of Context:
libdb/docs/ref/lock/max.html
1
 
<!--$Id$-->
2
 
<!--Copyright 1997-2002 by Sleepycat Software, Inc.-->
3
 
<!--All rights reserved.-->
4
 
<!--See the file LICENSE for redistribution information.-->
5
 
<html>
6
 
<head>
7
 
<title>Berkeley DB Reference Guide: Configuring locking: sizing the system</title>
8
 
<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit.">
9
 
<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,java,C,C++">
10
 
</head>
11
 
<body bgcolor=white>
12
 
<a name="2"><!--meow--></a>
13
 
<table width="100%"><tr valign=top>
14
 
<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Locking Subsystem</dl></h3></td>
15
 
<td align=right><a href="../../ref/lock/config.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/lock/stdmode.html"><img src="../../images/next.gif" alt="Next"></a>
16
 
</td></tr></table>
17
 
<p>
18
 
<h1 align=center>Configuring locking: sizing the system</h1>
19
 
<p>The lock system is sized using the following three functions:
20
 
<p><blockquote><pre><a href="../../api_c/env_set_lk_max_locks.html">DB_ENV-&gt;set_lk_max_locks</a>
21
 
<a href="../../api_c/env_set_lk_max_lockers.html">DB_ENV-&gt;set_lk_max_lockers</a>
22
 
<a href="../../api_c/env_set_lk_max_objects.html">DB_ENV-&gt;set_lk_max_objects</a></pre></blockquote>
23
 
<p>The <a href="../../api_c/env_set_lk_max_locks.html">DB_ENV-&gt;set_lk_max_locks</a>, <a href="../../api_c/env_set_lk_max_lockers.html">DB_ENV-&gt;set_lk_max_lockers</a>,
24
 
and <a href="../../api_c/env_set_lk_max_objects.html">DB_ENV-&gt;set_lk_max_objects</a> methods specify the maximum number of
25
 
locks, lockers, and locked objects supported by the lock subsystem,
26
 
respectively.  The maximum number of locks is the number of locks that
27
 
can be simultaneously requested in the system.  The maximum number of
28
 
lockers is the number of lockers that can simultaneously request locks
29
 
in the system.  The maximum number of lock objects is the number of
30
 
objects that can simultaneously be locked in the system.  Selecting
31
 
appropriate values requires an understanding of your application and
32
 
its databases.  If the values are too small, requests for locks in an
33
 
application will fail.  If the values are too large, the locking
34
 
subsystem will consume more resources than is necessary.  It is better
35
 
to err in the direction of allocating too many locks, lockers, and
36
 
objects because increasing the number of locks does not require large
37
 
amounts of additional resources.
38
 
<p>The recommended algorithm for selecting the maximum number of locks,
39
 
lockers, and lock objects is to run the application under stressful
40
 
conditions and then review the lock system's statistics to determine
41
 
the maximum number of locks, lockers, and lock objects that were used.
42
 
Then, double these values for safety.  However, in some large
43
 
applications, finer granularity of control is necessary in order to
44
 
minimize the size of the Lock subsystem.
45
 
<p>The maximum number of lockers can be estimated as follows:
46
 
<p><ul type=disc>
47
 
<li>If the database environment is configured to use transactions, the
48
 
maximum number of lockers needed is the number of simultaneously active
49
 
transactions and child transactions (where a child transaction is active
50
 
until its parent commits or aborts, not until it commits or aborts).
51
 
<li>If the database environment is not configured to use transactions, the
52
 
maximum number of lockers needed is the number of simultaneous
53
 
non-cursor operations plus an additional locker for every simultaneously
54
 
open cursor.
55
 
</ul>
56
 
<p>The maximum number of lock objects needed can be estimated as follows:
57
 
<p><ul type=disc>
58
 
<li>For Btree and Recno access methods, you will need one lock object per
59
 
level of the database tree, at a minimum.  (Unless keys are quite large
60
 
with respect to the page size, neither Recno nor Btree database trees
61
 
should ever be deeper than five levels.)  Then, you will need one lock
62
 
object for each leaf page of the database tree that will be
63
 
simultaneously accessed.
64
 
<li>For the Queue access method, you will need one lock object per record
65
 
that is simultaneously accessed.  To this, add one lock object per page
66
 
that will be simultaneously accessed.  (Because the Queue access method
67
 
uses fixed-length records and the database page size is known, it is
68
 
possible to calculate the number of pages -- and, therefore, the lock
69
 
objects -- required.)  Deleted records skipped by a <a href="../../api_c/dbc_get.html#DB_NEXT">DB_NEXT</a> or
70
 
<a href="../../api_c/dbc_get.html#DB_PREV">DB_PREV</a> operation do not require a separate lock object.
71
 
Further, if your application is using transactions, no database
72
 
operation will ever use more than three lock objects at any time.
73
 
<li>For the Hash access method, you only need a single lock object.
74
 
</ul>
75
 
<p>For all access methods, you should then add an additional lock object
76
 
per database for the database's metadata page.
77
 
<p>The maximum number of locks required by an application cannot be easily
78
 
estimated.  It is possible to calculate a maximum number of locks by
79
 
multiplying the maximum number of lockers, times the maximum number of
80
 
lock objects, times two (two for the two possible lock modes for each
81
 
object, read and write).  However, this is a pessimal value, and real
82
 
applications are unlikely to actually need that many locks.  Reviewing
83
 
the Lock subsystem statistics is the best way to determine this value.
84
 
<table width="100%"><tr><td><br></td><td align=right><a href="../../ref/lock/config.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/lock/stdmode.html"><img src="../../images/next.gif" alt="Next"></a>
85
 
</td></tr></table>
86
 
<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font>
87
 
</body>
88
 
</html>