[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: write-scaling problems in LMDB
On Mon, Oct 20, 2014 at 3:25 PM, Howard Chu <hyc@symas.com> wrote:
> Luke Kenneth Casson Leighton wrote:
>>
>> On Mon, Oct 20, 2014 at 2:34 PM, Howard Chu <hyc@symas.com> wrote:
>>>
>>> I can probably use taskset or something similar to restrict a process to
>>> a
>>> particular set of cores. What exactly do you have in mind?
>>
>>
>> keeping the writers and readers proposed test, but onto the same 8
>> cores only, running:
>
>
> Well in the meantime, the 32/32 test finished:
>
> Writers Run Time CPU % Context
> Switches Write Read Run Time
> CPU %
> Wall User Sys Vol
> Invol Wall User Sys
> 1 10:01.38 00:09:34.90 00:00:25.80 99 9
> 2040 27160 5877894 10:00.68 05:19:03.44 00:00:35.34 3192
> 2 10:01.38 00:09:15.15 00:02:41.94 119 14397526
> 2955 24012 6150801 10:00.67 05:19:00.96 00:00:38.23 3192
> 4 10:01.34 00:09:06.93 00:02:46.94 118 14246971
> 8545 23795 6067928 10:00.68 05:18:59.65 00:00:39.52 3192
> 8 10:01.49 00:09:04.22 00:02:53.09 119 14011236
> 10850 23589 5961381 10:00.69 05:18:56.82 00:00:42.54 3192
> 16 10:01.64 00:09:07.32 00:02:53.09 119 13787738
> 20049 23670 5966794 10:00.68 05:18:59.13 00:00:40.35 3192
> 32 10:01.78 00:09:04.29 00:02:58.40 120 13205576
> 27847 23337 5959624 10:00.70 05:19:00.54 00:00:39.46 3192
>
> The timings on the left are for the writer process; the reader process
> is on the right. You were right, the number of writers is largely
> irrelevant because they're all waiting most of the time. There's a
> huge jump in System CPU time from 1 writer to 2 writers, because with
> only 1 writer the mutex is uncontended and essentially zero-cost. As
> more writer threads are added, the System CPU time will rise.
by some 15 to 20% or so, from 2 writers going up to 32 writers.
which is not unreasonable - nothing like what i saw (CPU usage
dropping to 40%, loadavg jumping to over 8x the number of cores).
ok... what's the number of writes being carried out in each
transaction? the original scenario in which i saw the issue was when
there was one (!!). the design at the time was not optimised for
batches of reads followed by batches of writes.
a single write per transaction would mean quite a lot more mutex usage.
l.