>>> Geoff Swan <gswan3(a)bigpond.net.au> schrieb am
21.04.2015 um 23:19 in Nachricht
> 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
>>>> <reichert(a)numachi.com> 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
>>>> rule of thumb with bdb/hdb. So far in playing with back-mdb, it's
>>>> 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
>> 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.
Did you try NOT tuning those? A swapped in-memory database is not the thing you usually
Swappiness for an out-of-the-box kernel was 60, which sounds way too
high. So I reduced it to 10.