# $OpenLDAP$
-# Copyright 1999-2007 The OpenLDAP Foundation, All Rights Reserved.
+# Copyright 1999-2013 The OpenLDAP Foundation, All Rights Reserved.
# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
H1: Tuning
Scale your cache to use available memory and increase system memory if you can.
-More info here.
+See {{SECT:Caching}} for BDB cache tuning hints.
+Note that LMDB uses no cache of its own and has no tuning options, so the Caching
+section can be ignored when using LMDB.
H3: Disks
-Use fast subsystems. Put each database and logs on separate disks.
+Use fast filesystems, and conduct your own testing to see which filesystem
+types perform best with your workload. (On our own Linux testing, EXT2 and JFS
+tend to provide better write performance than everything else, including
+newer filesystems like EXT4, BTRFS, etc.)
-Example showing config settings
+Use fast subsystems. Put each database and logs on separate disks
+(for BDB this is configurable via {{DB_CONFIG}}):
+
+> # Data Directory
+> set_data_dir /data/db
+>
+> # Transaction Log settings
+> set_lg_dir /logs
H3: Network Topology
H2: Indexes
-http://www.openldap.org/faq/data/cache/42.html
-http://www.connexitor.com/blog/pivot/entry.php?id=103#body
-http://groups.google.com/group/comp.mail.sendmail/browse_frm/thread/17c5c0b94ad1fc58/f870758659375718?lnk=gst&q=hyc&rnum=12&hl=en#f870758659375718
+H3: Understanding how a search works
+
+If you're searching on a filter that has been indexed, then the search reads
+the index and pulls exactly the entries that are referenced by the index.
+If the filter term has not been indexed, then the search must read every single
+ entry in the target scope and test to see if each entry matches the filter.
+Obviously indexing can save a lot of work when it's used correctly.
+
+H3: What to index
+
+You should create indices to match the actual filter terms used in
+search queries.
+
+> index cn,sn,givenname,mail eq
+
+Each attribute index can be tuned further by selecting the set of index types to generate. For example, substring and approximate search for organizations (o) may make little sense (and isn't like done very often). And searching for {{userPassword}} likely makes no sense what so ever.
+
+General rule: don't go overboard with indexes. Unused indexes must be maintained and hence can only slow things down.
+
+See {{slapd.conf}}(8) and {{slapdindex}}(8) for more information
+
+
+H3: Presence indexing
+
+If your client application uses presence filters and if the
+target attribute exists on the majority of entries in your target scope, then
+all of those entries are going to be read anyway, because they are valid
+members of the result set. In a subtree where 100% of the
+entries are going to contain the same attributes, the presence index does
+absolutely NOTHING to benefit the search, because 100% of the entries match
+that presence filter.
+
+So the resource cost of generating the index is a
+complete waste of CPU time, disk, and memory. Don't do it unless you know
+that it will be used, and that the attribute in question occurs very
+infrequently in the target data.
+
+Almost no applications use presence filters in their search queries. Presence
+indexing is pointless when the target attribute exists on the majority of
+entries in the database. In most LDAP deployments, presence indexing should
+not be done, it's just wasted overhead.
+
+See the {{Logging}} section below on what to watch our for if you have a frequently searched
+for attribute that is unindexed.
+
+
+H2: Logging
+
+H3: What log level to use
+
+The default of {{loglevel stats}} (256) is really the best bet. There's a corollary to
+this when problems *do* arise, don't try to trace them using syslog.
+Use the debug flag instead, and capture slapd's stderr output. syslog is too
+slow for debug tracing, and it's inherently lossy - it will throw away messages when it
+can't keep up.
+Contrary to popular belief, {{loglevel 0}} is not ideal for production as you
+won't be able to track when problems first arise.
-H2: Tuning Logging
+H3: What to watch out for
-http://www.openldap.org/faq/data/cache/80.html
+The most common message you'll see that you should pay attention to is:
+> "<= bdb_equality_candidates: (foo) index_param failed (18)"
-H2: BDB/HDB Database Caching
+That means that some application tried to use an equality filter ({{foo=<somevalue>}})
+and attribute {{foo}} does not have an equality index. If you see a lot of these
+messages, you should add the index. If you see one every month or so, it may
+be acceptable to ignore it.
+
+The default syslog level is stats (256) which logs the basic parameters of each
+request; it usually produces 1-3 lines of output. On Solaris and systems that
+only provide synchronous syslog, you may want to turn it off completely, but
+usually you want to leave it enabled so that you'll be able to see index
+messages whenever they arise. On Linux you can configure syslogd to run
+asynchronously, in which case the performance hit for moderate syslog traffic
+pretty much disappears.
+
+H3: Improving throughput
+
+You can improve logging performance on some systems by configuring syslog not
+to sync the file system with every write ({{man syslogd/syslog.conf}}). In Linux,
+you can prepend the log file name with a "-" in {{syslog.conf}}. For example,
+if you are using the default LOCAL4 logging you could try:
+
+> # LDAP logs
+> LOCAL4.* -/var/log/ldap
+
+For syslog-ng, add or modify the following line in {{syslog-ng.conf}}:
+
+> options { sync(n); };
+
+where n is the number of lines which will be buffered before a write.
+
+
+H2: Caching
We all know what caching is, don't we?
In brief, "A cache is a block of memory for temporary storage of data likely
-to be used again" - http://en.wikipedia.org/wiki/Cache
+to be used again" - {{URL:http://en.wikipedia.org/wiki/Cache}}
+
+There are 3 types of caches, BerkeleyDB's own cache, {{slapd}}(8)
+entry cache and {{TERM:IDL}} (IDL) cache.
+
+
+H3: Berkeley DB Cache
+
+There are two ways to tune for the BDB cachesize:
+
+(a) BDB cache size necessary to load the database via slapadd in optimal time
+
+(b) BDB cache size necessary to have a high performing running slapd once the data is loaded
+
+For (a), the optimal cachesize is the size of the entire database. If you
+already have the database loaded, this is simply a
+
+> du -c -h *.bdb
+
+in the directory containing the OpenLDAP ({{/usr/local/var/openldap-data}}) data.
-Caching - memory is good, more is better. If the entire database fits in RAM, that's ideal. There are multiple caches involved - first is BerkeleyDB's own data cache which operates on page-sized blocks of raw data. Then there's the slapd entry cache which operates on decoded entries. Note that while the BDB cache is just raw chunks of memory and configured as a memory size, the slapd entry cache holds parsed entries, and the size of each entry is variable. There is also an IDL cache which is used for Index Data Lookups. If you can fit all of your database into slapd's entry cache, and all of your index lookups fit in the IDL cache, that will provide the maximum throughput. If not, but you can fit the entire database into the BDB cache, then you should do that and shrink the slapd entry cache as appropriate. Failing that, you should balance the BDB cache against the entry cache.
+For (b), the optimal cachesize is just the size of the {{id2entry.bdb}} file,
+plus about 10% for growth.
-The rationale - entries in the entry cache can be used directly, giving the fastest response. If an entry isn't in the entry cache but can be extracted from the BDB page cache, that will avoid an I/O but it will still require parsing, so this will be slower. If the entry is in neither cache then BDB will have to flush some of its current cached pages and bring in the needed pages, resulting in a couple of expensive I/Os as well as parsing.
+The tuning of {{DB_CONFIG}} should be done for each BDB type database
+instantiated (back-bdb, back-hdb).
-As far as balancing the entry cache vs the BDB cache - parsed entries in memory are generally about twice as large as they are on disk.
+Note that while the {{TERM:BDB}} cache is just raw chunks of memory and
+configured as a memory size, the {{slapd}}(8) entry cache holds parsed entries,
+and the size of each entry is variable.
-Not having a proper database cache size will cause performance issues.
+There is also an IDL cache which is used for Index Data Lookups.
+If you can fit all of your database into slapd's entry cache, and all of your
+index lookups fit in the IDL cache, that will provide the maximum throughput.
-These issues are not an indication of corruption occurring in the database. It is merely the fact that the cache is thrashing itself that causes performance/response time to slowdown. If you take the time to read and understand the Berkeley DB documentation, measure the library performance using db_stat, and tune your settings, you will avoid these problems.
+If not, but you can fit the entire database into the BDB cache, then you
+should do that and shrink the slapd entry cache as appropriate.
-It is not absolutely necessary to configure a BerkeleyDB cache equal in size to your entire database. All that you need is a cache that's large enough for your "working set." That means, large enough to hold all of the most frequently accessed data, plus a few less-frequently accessed items.
+Failing that, you should balance the BDB cache against the entry cache.
-You should really read the BDB documentation referenced above, but let me spell out what that really means here, in detail. The discussion here is focused on back-bdb and back-hdb, but most of it also applies to back-ldbm when using BerkeleyDB as the underlying database engine.
+It is worth noting that it is not absolutely necessary to configure a BerkeleyDB
+cache equal in size to your entire database. All that you need is a cache
+that's large enough for your "working set."
-Start with the most obvious - the back-bdb database lives in two main files, dn2id.bdb and id2entry.bdb. These are B-tree databases. We have never documented the back-bdb internal layout before, because it didn't seem like something anyone should have to worry about, nor was it necessarily cast in stone. But here's how it works today, in OpenLDAP 2.1 and 2.2. (All of the database files in back-ldbm are B-trees by default.)
+That means, large enough to hold all of the most frequently accessed data,
+plus a few less-frequently accessed items.
-A B-tree is a balanced tree; it stores data in its leaf nodes and bookkeeping data in its interior nodes. (If you don't know what tree data structures look like in general, Google for some references, because that's getting far too elementary for the purposes of this discussion.)
+For more information, please see: {{URL:http://www.oracle.com/technology/documentation/berkeley-db/db/ref/am_conf/cachesize.html}}
-For decent performance, you need enough cache memory to contain all the nodes along the path from the root of the tree down to the particular data item you're accessing. That's enough cache for a single search. For the general case, you want enough cache to contain all the internal nodes in the database. "db_stat -d" will tell you how many internal pages are present in a database. You should check this number for both dn2id and id2entry.
+H4: Calculating Cachesize
-Also note that id2entry always uses 16KB per "page", while dn2id uses whatever the underlying filesystem uses, typically 4 or 8KB. To avoid thrashing the cache and triggering these infinite hang bugs in BDB 4.1.25, your cache must be at least as large as the number of internal pages in both the dn2id and id2entry databases, plus some extra space to accomodate the actual leaf data pages.
+The back-bdb database lives in two main files, {{F:dn2id.bdb}} and {{F:id2entry.bdb}}.
+These are B-tree databases. We have never documented the back-bdb internal
+layout before, because it didn't seem like something anyone should have to worry
+about, nor was it necessarily cast in stone. But here's how it works today,
+in OpenLDAP 2.4.
-For example, in my OpenLDAP 2.2 test database, I have an input LDIF file that's about 360MB. With the back-hdb backend this creates a dn2id.bdb that's 68MB, and an id2entry that's 800MB. db_stat tells me that dn2id uses 4KB pages, has 433 internal pages, and 6378 leaf pages. The id2entry uses 16KB pages, has 52 internal pages, and 45912 leaf pages. In order to efficiently retrieve any single entry in this database, the cache should be at least
+A B-tree is a balanced tree; it stores data in its leaf nodes and bookkeeping
+data in its interior nodes (If you don't know what tree data structures look
+ like in general, Google for some references, because that's getting far too
+elementary for the purposes of this discussion).
-(433+1) * 4KB + (52+1) * 16KB in size: 1736KB + 848KB =~ 2.5MB.
+For decent performance, you need enough cache memory to contain all the nodes
+along the path from the root of the tree down to the particular data item
+you're accessing. That's enough cache for a single search. For the general case,
+you want enough cache to contain all the internal nodes in the database.
-This doesn't take into account other library overhead, so this is even lower than the barest minimum. The default cache size, when nothing is configured, is only 256KB. If you tried to do much of anything with this database and only default settings, BDB 4.1.25 would lock up in an infinite loop.
+> db_stat -d
-This 2.5MB number also doesn't take indexing into account. Each indexed attribute uses another database file of its own, using a Hash structure. (Again, in back-ldbm, the indexes also use B-trees by default, so this part of the discussion doesn't apply unless back-ldbm was explicitly compiled to use Hashes instead. Also, in OpenLDAP 2.2 onward, all of the indexes use B-trees, there are no more Hash database files. So just use the B-tree information above and ignore this Hash discussion.)
+will tell you how many internal pages are present in a database. You should
+check this number for both dn2id and id2entry.
-Unlike the B-trees, where you only need to touch one data page to find an entry of interest, doing an index lookup generally touches multiple keys, and the point of a hash structure is that the keys are evenly distributed across the data space. That means there's no convenient compact subset of the database that you can keep in the cache to insure quick operation, you can pretty much expect references to be scattered across the whole thing. My strategy here would be to provide enough cache for at least 50% of all of the hash data. (Number of hash buckets + number of overflow pages + number of duplicate pages) * page size / 2.
+Also note that {{id2entry}} always uses 16KB per "page", while {{dn2id}} uses whatever
+the underlying filesystem uses, typically 4 or 8KB. To avoid thrashing,
+your cache must be at least as large as the number of internal pages in both
+the {{dn2id}} and {{id2entry}} databases, plus some extra space to accommodate
+the actual leaf data pages.
-The objectClass index for my example database is 5.9MB and uses 3 hash buckets and 656 duplicate pages. So ( 3 + 656 ) * 4KB / 2 =~ 1.3MB.
+For example, in my OpenLDAP 2.4 test database, I have an input LDIF file that's
+about 360MB. With the back-hdb backend this creates a {{dn2id.bdb}} that's 68MB,
+and an {{id2entry}} that's 800MB. db_stat tells me that {{dn2id}} uses 4KB pages, has
+433 internal pages, and 6378 leaf pages. The id2entry uses 16KB pages, has 52
+internal pages, and 45912 leaf pages. In order to efficiently retrieve any
+single entry in this database, the cache should be at least
-With only this index enabled, I'd figure at least a 4MB cache for this backend. (Of course you're using a single cache shared among all of the database files, so the cache pages will most likely get used for something other than what you accounted for, but this gives you a fighting chance.)
+> (433+1) * 4KB + (52+1) * 16KB in size: 1736KB + 848KB =~ 2.5MB.
-With this 4MB cache I can slapcat this entire database on my 1.3GHz PIII in 1 minute, 40 seconds. With the cache doubled to 8MB, it still takes the same 1:40s. Once you've got enough cache to fit the B-tree internal pages, increasing it further won't have any effect until the cache really is large enough to hold 100% of the data pages. I don't have enough free RAM to hold all the 800MB id2entry data, so 4MB is good enough.
+This doesn't take into account other library overhead, so this is even lower
+than the barest minimum. The default cache size, when nothing is configured,
+is only 256KB.
-With back-bdb and back-hdb you can use "db_stat -m" to check how well the database cache is performing. Unfortunately you can't do this with back-ldbm, as the statistics are not accessible when slapd is running, nor are they saved anywhere when slapd is stopped. (Yet another reason not to use back-ldbm.)
-hyc@openldap.org, Kurt@OpenLDAP.org
-NOTE: This is unrelated to the entry cache. See also: (Xref) Can I tune the BDB entry cache?
-If you want to setup the cache size, please read:
+This 2.5MB number also doesn't take indexing into account. Each indexed
+attribute results in another database file. Earlier versions of OpenLDAP
+kept these index databases in Hash format, but from OpenLDAP 2.2 onward
+the index databases are in B-tree format so the same procedure can
+be used to calculate the necessary amount of cache for each index database.
- (Xref) How do I configure the BDB backend?
- (Xref) What are the DB_CONFIG configuration directives?
- http://www.sleepycat.com/docs/utility/db_recover.html
+For example, if your only index is for the objectClass attribute and db_stat
+reveals that {{objectClass.bdb}} has 339 internal pages and uses 4096 byte
+pages, the additional cache needed for just this attribute index is
-A default config can be found in the answer:
+> (339+1) * 4KB =~ 1.3MB.
- (Xref) What are the DB_CONFIG configuration directives?
+With only this index enabled, I'd figure at least a 4MB cache for this backend.
+(Of course you're using a single cache shared among all of the database files,
+so the cache pages will most likely get used for something other than what you
+accounted for, but this gives you a fighting chance.)
-just change the set_lg_dir to point to your .log directory or comment that line.
+With this 4MB cache I can slapcat this entire database on my 1.3GHz PIII in
+1 minute, 40 seconds. With the cache doubled to 8MB, it still takes the same 1:40s.
+Once you've got enough cache to fit the B-tree internal pages, increasing it
+further won't have any effect until the cache really is large enough to hold
+100% of the data pages. I don't have enough free RAM to hold all the 800MB
+id2entry data, so 4MB is good enough.
-Quick guide:
-- Create a DB_CONFIG file in your ldap home directory (/var/lib/ldap/DB_CONFIG) with the correct "set_cachesize" value
-- stop your ldap server and run db_recover -h /var/lib/ldap
-- start your ldap server and check the new cache size with:
+With back-bdb and back-hdb you can use "db_stat -m" to check how well the
+database cache is performing.
- db_stat -h /var/lib/ldap -m | head -n 2
+For more information on {{db_stat}}: {{URL:http://www.oracle.com/technology/documentation/berkeley-db/db/utility/db_stat.html}}
-- this procedure is only needed if you use OpenLDAP 2.2 with the BDB or HDB backends; In OpenLDAP 2.3 DB recovery is performed automatically whenever the DB_CONFIG file is changed or when an unclean shutdown is detected.
+H3: {{slapd}}(8) Entry Cache (cachesize)
+The {{slapd}}(8) entry cache operates on decoded entries. The rationale - entries
+in the entry cache can be used directly, giving the fastest response. If an entry
+isn't in the entry cache but can be extracted from the BDB page cache, that will
+avoid an I/O but it will still require parsing, so this will be slower.
---On Tuesday, February 22, 2005 12:15 PM -0500 Dusty Doris <openldap@mail.doris.cc> wrote:
+If the entry is in neither cache then BDB will have to flush some of its current
+cached pages and bring in the needed pages, resulting in a couple of expensive
+I/Os as well as parsing.
- Few questions, if you change the cachesize and idlecachesize entries, do
- you have to do anything special aside from restarting slapd, such as run
- slapindex or db_recover?
+The most optimal value is of course, the entire number of entries in the database.
+However, most directory servers don't consistently serve out their entire database, so setting this to a lesser number that more closely matches the believed working set of data is
+sufficient. This is the second most important parameter for the DB.
+As far as balancing the entry cache vs the BDB cache - parsed entries in memory
+are generally about twice as large as they are on disk.
- Also, is there any way to tell how much memory these caches are taking up
- to make sure they are not set too large? What happens if you set your
- cachesize too large and you don't have enough available memory to store
- these? Will that cause an issue with openldap, or will it just not cache
- those entries that would make it exceed its available memory. Will it
- just use some sort of FIFO on those caches?
+As we have already mentioned, not having a proper database cache size will
+cause performance issues. These issues are not an indication of corruption
+occurring in the database. It is merely the fact that the cache is thrashing
+itself that causes performance/response time to slowdown.
-It will consume the memory resources of your system, and likely cause issues.
+H3: {{TERM:IDL}} Cache (idlcachesize)
- Finally, what do most people try to achieve with these values? Would the
- goal be to make these as big as the directory? So, if I have 400,000 dn's
- in my directory, would it be safe to set these at 400000 or would
- something like 20,000 be good enough to get a nice performance increase?
+Each IDL holds the search results from a given query, so the IDL cache will
+end up holding the most frequently requested search results. For back-bdb,
+it is generally recommended to match the "cachesize" setting. For back-hdb,
+it is generally recommended to be 3x"cachesize".
+{NOTE: The idlcachesize setting directly affects search performance}
-I try to cache the most actively used entries. Unless you expect all 400,000 entries of your DB to be accessed regularly, there is no need to cache that many entries. My entry cache is set to 20,000 (out of a little over 400,000 entries).
-The idl cache has to do with how many unique result sets of searches you want to store in memory. Setting up this cache will allow your most frequently placed searches to get results much faster, but I doubt you want to try and cache the results of every search that hits your system. ;)
+H2: {{slapd}}(8) Threads
---Quanah
+{{slapd}}(8) can process requests via a configurable number of threads, which
+in turn affects the in/out rate of connections.
+This value should generally be a function of the number of "real" cores on
+the system, for example on a server with 2 CPUs with one core each, set this
+to 8, or 4 threads per real core. This is a "read" maximized value. The more
+threads that are configured per core, the slower {{slapd}}(8) responds for
+"read" operations. On the flip side, it appears to handle write operations
+faster in a heavy write/low read scenario.
-http://www.openldap.org/faq/data/cache/1076.html
+The upper bound for good read performance appears to be 16 threads (which
+also happens to be the default setting).
projects / openldap / blobdiff