I'm using OpenLDAP 2.4.7 with BerkeleyDB 4.6 on Solaris-10 hosts. We haven't been using it in production so I don't have any real experience with the performance under load. I'll be looking into doing some simulated load tests later. Right now, I'd like to understand more about performance tuning.
I'm trying to follow the instruction in the FAQ or OpenLDAP Software 2.4 Administrator's Guide section 19.4.1.1 Calculating Cachesize but can't find information that is needed to calculate the cache needed for various indexes. In particular the formula given near the end of that section talks about the "Number of hash buckets". I've found something that could be it from running db_stat -m command's output, but that seems to be a single number for the whole database not one per index. Would someone point me in the right direction?
BTW, I get much larger cachesize using the Admin Guide/FAQ method vs. the method Quanah Gibson-Mount wrote about in this mailing list. (du -c -h *.bdb in the database directory) Is that expected?
I assume it would be best to try to optimize the cachesize for all databases. Does this include the log database used for delta-syncrepl?
Also, is it better (performance wise) to give more memory to the db cache or the entry or idl caches? I couldn't find a clear answer from the Admin Guide, FAQ, nor the mailing list.
Finally, is there any difference tuning bdb vs. hdb? I would think not, but since I'm asking...
Thanks. Roy
--On Wednesday, February 06, 2008 3:12 PM -0500 "Marantz, Roy" Roy.Marantz@deshaw.com wrote:
Also, is it better (performance wise) to give more memory to the db cache or the entry or idl caches? I couldn't find a clear answer from the Admin Guide, FAQ, nor the mailing list.
Finally, is there any difference tuning bdb vs. hdb? I would think not, but since I'm asking...
General guide to OpenLDAP tuning:
There are a number of parameters that will affect performance. The ones with the most impact are:
BDB Cache size cachesize idlcachesize threads index
The first three of these settings have to do with the database. The "threads" parameter affects the in/out rate of connections. The "index" setting directly affects search performance.
Database tuning:
Of the three database paramemters, the BDB cache size is the most important. 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 performant 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 data.
For (b), the optimal cachesize is just the size of the id2entry.bdb file, plus about 10% for growth.
The tuning of DB_CONFIG should be done for each BDB type database instantiated (back-bdb, back-hdb).
The slapd.conf "cachesize" setting: The number of entries to store in the entry cache for slapd. The most optimal value is of course, the entire number of entries in the database. However, most LDAP 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.
The slapd.conf "idlcachesize" setting: 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, this is generally recommended to match the "cachesize" setting. For back-hdb, this is generally recommended to be 3x"cachesize".
Slapd tuning:
"threads": This directive sets the number of threads that slapd uses to process requests. What this value should be I've generally found to be a function of the number of "real" cores on the system. I.e., on a 2 CPU box with one core each, I 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 responds for "read" operations. On the flip side, it appears to handle write operations faster in a heavy write/low read scenario.
Search tuning:
"index": This creates indices on various attributes in the database to speed up searching. Know your searches, and configure indices appropriately.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
Slapd tuning:
"threads": This directive sets the number of threads that slapd uses to process requests. What this value should be I've generally found to be a function of the number of "real" cores on the system. I.e., on a 2 CPU box with one core each, I 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 responds for "read" operations. On the flip side, it appears to handle write operations faster in a heavy write/low read scenario.
The upper bound for good read performance appears to be 16 threads (which also happens to be slapd's default). This is also the setting I used when benchmarking the 8-core AMD and Intel servers; increasing beyond that consumed more CPU time but didn't improve throughput. http://connexitor.com/blog/pivot/entry.php?id=191
I believe this points to a bottleneck in OpenLDAP's thread pool implementation; for example on a Sun Niagara T2 system with 64 hardware threads, with only 16 threads we can only make effective use of 25% of the machine's CPU power. Using more threads in slapd only degrades the throughput. I'll be looking more closely at this in a few weeks.
--On Thursday, February 07, 2008 10:43 AM -0800 Howard Chu hyc@symas.com wrote:
Quanah Gibson-Mount wrote:
Slapd tuning:
"threads": This directive sets the number of threads that slapd uses to process requests. What this value should be I've generally found to be a function of the number of "real" cores on the system. I.e., on a 2 CPU box with one core each, I 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 responds for "read" operations. On the flip side, it appears to handle write operations faster in a heavy write/low read scenario.
The upper bound for good read performance appears to be 16 threads (which also happens to be slapd's default). This is also the setting I used when benchmarking the 8-core AMD and Intel servers; increasing beyond that consumed more CPU time but didn't improve throughput. http://connexitor.com/blog/pivot/entry.php?id=191
Okay, so 8 or 16 threads then. Because I know that on my dual-CPU boxes, 16 was definitely less performant than 8 threads.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-software@openldap.org
-
Howard Chu -
Marantz, Roy -
Quanah Gibson-Mount