← Back to branch summary

~ubuntu-branches/ubuntu/feisty/openldap2.3/feisty-updates

« back to all changes in this revision

Viewing changes to doc/guide/admin/tuning.sdf

  • Committer: Bazaar Package Importer
  • Author(s): Matthijs Mohlmann
  • Date: 2006-11-11 11:24:42 UTC
  • Revision ID: james.westby@ubuntu.com-20061111112442-645qqio2u3fin0sj
Tags: upstream-2.3.29
Import upstream version 2.3.29

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/guide/admin/tuning.sdf
 
1
# $OpenLDAP: pkg/openldap-guide/admin/tuning.sdf,v 1.8.2.1 2006/01/03 22:16:03 kurt Exp $
 
2
# Copyright 1999-2006 The OpenLDAP Foundation, All Rights Reserved.
 
3
# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
 
4
 
 
5
H1: Performance Tuning
 
6
 
 
7
Note: this chapter needs to be updated to discuss BDB tuning.
 
8
 
 
9
There are several things you can do to tune the performance of
 
10
slapd for your system. Most of them have to do with the LDBM
 
11
backend. LDBM uses an index mechanism to store and retrieve
 
12
information in slapd. Each entry is assigned a unique ID, used to
 
13
refer to the entry in the indexes. A search for entries with a
 
14
surname of "Jensen", for example, would look up the index entry
 
15
"=JENSEN" in the surname index. The data returned is a list of
 
16
IDs of entries having that value for the surname attribute. We
 
17
have found several things to be useful in improving the
 
18
performance of this indexing scheme, especially on modify
 
19
operations.
 
20
 
 
21
 
 
22
 
 
23
H2: The allIDs threshold
 
24
 
 
25
Some index entries become so large as to be useless. For
 
26
example, if every entry in your database is a person entry, the
 
27
"=PERSON" index entry in the objectclass index contains every
 
28
entry. This returns very little useful information, and can cause
 
29
significant delays, especially on updates. To alleviate this
 
30
problem, we have introduced the idea of an allIDs index entry.
 
31
 
 
32
The allIDs entry stands for a real index entry containing the IDs
 
33
of every entry in the database, but it takes up very little space,
 
34
never needs updating, and can be manipulated quickly and
 
35
efficiently. The trade-off is that it does not prune the set of
 
36
candidate entries at all during a search. This must be done
 
37
using other, more "high-powered" index entries.
 
38
 
 
39
You can set the minimum number of IDs that an index entry may
 
40
contain before it turns into an allIDs block by changing the
 
41
{{EX: SLAPD_LDBM_MIN_MAXIDS}} variable in the
 
42
{{EX: include/ldapconfig.h}} file. The actual number is determined at
 
43
runtime by the LDBM backend, depending on the block size of
 
44
the underlying device (i.e., the number you provide is rounded up
 
45
to the nearest multiple of a block size).
 
46
 
 
47
 
 
48
 
 
49
H2: The entry cache
 
50
 
 
51
The LDBM backend can be configured to keep a cache of
 
52
entries in memory. Since the LDBM database spends much of its
 
53
time reading entries from the id2entry file into memory, this cache
 
54
can greatly speed performance. The trade-off is that the cache
 
55
uses some extra memory. The default cache size is 1000
 
56
entries. See the discussion of the cachesize option in Section
 
57
5.2.3 on LDBM configuration.
 
58
 
 
59
 
 
60
 
 
61
H2: The DB cache
 
62
 
 
63
The LDBM backend uses a number of disk-based index files. If
 
64
the underlying hash or B-tree package supports in-memory
 
65
caching of these files, performance can be greatly improved,
 
66
especially on modifies. The size of this in-memory file cache is
 
67
given by the dbcachesize option, discussed in more detail in
 
68
section 5.2.3 on LDBM configuration. The default {{EX: dbcachesize}} is
 
69
100K.
 
70
 
 
71
 
 
72
 
 
73
H2: Maintain the right indices
 
74
 
 
75
Finally, one of the best performance tune-ups you can do is to
 
76
make sure you are maintaining the right indices. Too few indices
 
77
can lead to poor search performance. Too many indices can
 
78
lead to poor update performance. For example, the LDBM
 
79
backend would be perfectly happy to maintain substring and
 
80
approximate indices for the {{EX: objectclass attribute}}, but this would
 
81
not be useful and would just slow down update operations. If
 
82
your database has many entries and is handling queries for
 
83
substring equality on the surname attribute, you should make
 
84
sure to maintain a surname substring index so these queries are
 
85
answered quickly.
 
86
 
 
87
So, take a look at the index lines in your slapd configuration file to
 
88
ensure that only those indices that make sense and are needed
 
89
are being maintained.
 
90