Re: Antw: Re: Slapd running very slow

[Geoff Swan <gswan3@bigpond.net.au>]

On 2015-04-22 11:45 PM, Ulrich Windl wrote:
>>>> Geoff Swan <gswan3@bigpond.net.au> schrieb am 22.04.2015 um 14:06 in Nachricht
> <55378EE0.40103@bigpond.net.au>:
>
>> On 2015-04-22 4:49 PM, Ulrich Windl wrote:
> [...]
>>>> 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.
> Did we see your "free" stats? On a server running SLES11 SP3 (kernel 3.0.101) with similar memory (no slapd, but a huge Oracle and a NFS Server) I have:
> # free
>              total       used       free     shared    buffers     cached
> Mem:     132156276  131202644     953632   40317620    5219804   95059508
> -/+ buffers/cache:   30923332  101232944
> Swap:     20956756     165852   20790904
>
> I believe what the system pages out is really "dead meat". According to sar there is little actual paging:
>
> 00:00:01     pgpgin/s pgpgout/s   fault/s  majflt/s  pgfree/s pgscank/s pgscand/s pgsteal/s    %vmeff
> 11:00:01     12671.34   1979.03   4469.13      0.00   3412.08      0.00      0.00      0.00      0.00
> 11:10:01     11598.11   1693.74   4949.54      0.01   3466.14      0.00      0.00      0.00      0.00
> 11:20:01     12141.05   4759.01   4219.09      0.02   3753.33      0.00      0.00      0.00      0.00
> 11:30:01     14619.11   1562.84   4185.04      0.00   3134.25      0.00      0.00      0.00      0.00
>
> (Most "fage faults" are due to processes staring and ending with demand paging, I guess)
>
> Regards,
> Ulrich
>
Free stats look fine to me. No swap is being used, or has been used yet
on this system.

             total       used       free     shared    buffers     cached
Mem:     132005400   21928192  110077208      10612     363064   19230072
-/+ buffers/cache:    2335056  129670344
Swap:      8388604          0    8388604

The effect I am seeing is that despite a reasonably fast disc system,
the kernel writing of dirty pages is painfully slow.