Re: Antw: Re: Slapd running very slow

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

On 2015-04-23 4:43 PM, Howard Chu wrote:
> Geoff Swan wrote:
>>
>>
>> On 2015-04-23 4:07 PM, Ulrich Windl wrote:
>>>>>> Geoff Swan <gswan3@bigpond.net.au> schrieb am 22.04.2015 um 23:18
>>>>>> in Nachricht
>>> <5538100A.3060301@bigpond.net.au>:
>>>
>>> [...]
>>>> 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.
>>> So disk I/O stats is also available via sar. May we see them?
>>> Finally there's blktrace where you can follow the timing and
>>> positions of each individual block being written, but that's not
>>> quite easy to run and analyze (unless I missed the easy way).
>>>
>>> I suspect scattered writes that bring your I/O rate down.
>>>
>>> Regards,
>>> Ulrich
>>>
>> sysstat (and sar) is not installed on this system, so I can't give you
>> that output.
>
> As I said in my previous email - use iostat and/or vmstat to monitor
> paging activity and system wait time. You can also install atop and
> get all of the relevant stats on one screen.
>
> http://www.atoptool.nl/
>
> I find it indispensible these days.
>
BTW, just using nmon whilst running a test script that writes 20K small
objects shows a write speed of around 3-5 MB/s to the disc (without
dbnosync, so as to see the immediate effects). This is on a SAS disc
with a 140MB/s capability, checked using regular tools such a dd
(writing 1000 files of 384K each). I'm failing to understand why the
write operations from the kernel page cache is so drastically slower.
With dbnosync enabled, lmdb writes to the pages fast (as expected),
however the pdflush that follows writes at the same slow speed, causing
delays for further processes.