git.sur5r.net Git - openldap/blob - doc/guide/admin/tuning.sdf

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