← 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/am_misc/tune.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/am_misc/tune.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: Access method tuning</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><a name="3"><!--meow--></a>
13
 
<table width="100%"><tr valign=top>
14
 
<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Access Methods</dl></h3></td>
15
 
<td align=right><a href="../../ref/am_misc/diskspace.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/am_misc/faq.html"><img src="../../images/next.gif" alt="Next"></a>
16
 
</td></tr></table>
17
 
<p>
18
 
<h1 align=center>Access method tuning</h1>
19
 
<p>There are a few different issues to consider when tuning the performance
20
 
of Berkeley DB access method applications.
21
 
<p><dl compact>
22
 
<p><dt>access method<dd>An application's choice of a database access method can significantly
23
 
affect performance.  Applications using fixed-length records and integer
24
 
keys are likely to get better performance from the Queue access method.
25
 
Applications using variable-length records are likely to get better
26
 
performance from the Btree access method, as it tends to be faster for
27
 
most applications than either the Hash or Recno access methods.  Because
28
 
the access method APIs are largely identical between the Berkeley DB access
29
 
methods, it is easy for applications to benchmark the different access
30
 
methods against each other.  See <a href="../../ref/am_conf/select.html">Selecting an access method</a> for more information.
31
 
<p><dt>cache size<dd>The Berkeley DB database cache defaults to a fairly small size, and most
32
 
applications concerned with performance will want to set it explicitly.
33
 
Using a too-small cache will result in horrible performance.  The first
34
 
step in tuning the cache size is to use the db_stat utility (or the
35
 
statistics returned by the <a href="../../api_c/db_stat.html">DB-&gt;stat</a> function) to measure the
36
 
effectiveness of the cache.  The goal is to maximize the cache's hit
37
 
rate.  Typically, increasing the size of the cache until the hit rate
38
 
reaches 100% or levels off will yield the best performance.  However,
39
 
if your working set is sufficiently large, you will be limited by the
40
 
system's available physical memory.  Depending on the virtual memory
41
 
and file system buffering policies of your system, and the requirements
42
 
of other applications, the maximum cache size will be some amount
43
 
smaller than the size of physical memory.  If you find that
44
 
<a href="../../utility/db_stat.html">db_stat</a> shows that increasing the cache size improves your hit
45
 
rate, but performance is not improving (or is getting worse), then it's
46
 
likely you've hit other system limitations.  At this point, you should
47
 
review the system's swapping/paging activity and limit the size of the
48
 
cache to the maximum size possible without triggering paging activity.
49
 
Finally, always remember to make your measurements under conditions as
50
 
close as possible to the conditions your deployed application will run
51
 
under, and to test your final choices under worst-case conditions.
52
 
<p><dt>shared memory<dd>By default, Berkeley DB creates its database environment shared regions in
53
 
filesystem backed memory.  Some systems do not distinguish between
54
 
regular filesystem pages and memory-mapped pages backed by the
55
 
filesystem, when selecting dirty pages to be flushed back to disk.  For
56
 
this reason, dirtying pages in the Berkeley DB cache may cause intense
57
 
filesystem activity, typically when the filesystem sync thread or
58
 
process is run.  In some cases, this can dramatically affect application
59
 
throughput.  The workaround to this problem is to create the shared
60
 
regions in system shared memory (<a href="../../api_c/env_open.html#DB_SYSTEM_MEM">DB_SYSTEM_MEM</a>) or in
61
 
application private memory (<a href="../../api_c/env_open.html#DB_PRIVATE">DB_PRIVATE</a>).
62
 
<p><dt>large key/data items<dd>Storing large key/data items in a database can alter the performance
63
 
characteristics of Btree, Hash and Recno databases.  The first parameter
64
 
to consider is the database page size.  When a key/data item is too
65
 
large to be placed on a database page, it is stored on "overflow" pages
66
 
that are maintained outside of the normal database structure (typically,
67
 
items that are larger than one-quarter of the page size are deemed to
68
 
be too large).  Accessing these overflow pages requires at least one
69
 
additional page reference over a normal access, so it is usually better
70
 
to increase the page size than to create a database with a large number
71
 
of overflow pages.  Use the <a href="../../utility/db_stat.html">db_stat</a> utility (or the statistics
72
 
returned by the <a href="../../api_c/db_stat.html">DB-&gt;stat</a> method) to review the number of overflow
73
 
pages in the database.
74
 
<p>The second issue is using large key/data items instead of duplicate data
75
 
items.  While this can offer performance gains to some applications
76
 
(because it is possible to retrieve several data items in a single get
77
 
call), once the key/data items are large enough to be pushed off-page,
78
 
they will slow the application down.  Using duplicate data items is
79
 
usually the better choice in the long run.
80
 
</dl>
81
 
<table width="100%"><tr><td><br></td><td align=right><a href="../../ref/am_misc/diskspace.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/am_misc/faq.html"><img src="../../images/next.gif" alt="Next"></a>
82
 
</td></tr></table>
83
 
<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font>
84
 
</body>
85
 
</html>