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.