[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Antw: Re: Slapd running very slow




On 2015-04-22 4:49 PM, Ulrich Windl wrote:
>>>> Geoff Swan <gswan3@bigpond.net.au> schrieb am 21.04.2015 um 23:19 in Nachricht
> <5536BEC9.3040902@bigpond.net.au>:
>
>> 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@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 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.
> Did you try NOT tuning those? A swapped in-memory database is not the thing you usually want.
>
Swappiness for an out-of-the-box kernel was 60, which sounds way too
high. So I reduced it to 10.

>