On 2015-04-22 6:04 AM, Howard Chu wrote: > Brian Reichert wrote: >> On Tue, Apr 21, 2015 at 08:23:31AM -0700, Quanah Gibson-Mount wrote: >>> --On Tuesday, April 21, 2015 11:54 AM -0400 Brian Reichert >>> <[email protected]> wrote: >>>> What does your config file look like? >>>> >>>> In particular, what does this setting look like for you: >>>> >>>> # Threads - four per CPU >>>> threads 8 >>> >>> According to his summary, he's using 48 threads. >> >> Thanks for pointing that out; I should finish my coffee before >> posting. :) >> >>> 4 per CPU/core was a good >>> rule of thumb with bdb/hdb. So far in playing with back-mdb, it's >>> seemed >>> closer to 2 per CPU/core for me in benchmarking. Interesting. What is the relationship between the number of threads and the number of concurrent bind operations? If I have, say, 500 clients wanting access to perform simple authentication/bind and perform some read/write operation, how is this usually handled within slapd?
>> >> Useful to note. Has this detail ended up in any docs yet? > > No, nor should it. Performance depends on system environment and > workload - the right value is one that each site must discover for > themselves in their own deployment. > Are there any clues about key factors affecting this? Linux, in this case, has vm.swappiness set to 10, vm.dirty_ratio at 12 and vm.dirty_background at 3. However I've noticed that when dirty pages are flushed to disc, the system stalls. And that operation appears to take a relatively long time. Disc write speed should be close to 130MB/s (file copy, dd test etc) however it appears to be much slower than this with the page flush.
