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.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
