maria-developers team mailing list archive

[MARK CALLAGHAN <mdcallag@xxxxxxxxx>]

On Wed, Oct 21, 2009 at 3:04 PM, Michael Widenius <monty@xxxxxxxxxxxx> wrote:
>
> Hi!
>
>>>>>> "MARK" == MARK CALLAGHAN <mdcallag@xxxxxxxxx> writes:
>
> MARK> This includes results from sysbench for Maria 5.2 with/without
> MARK> userstat enabled and for several other binaries. The results are
> MARK> throughput (transactions per second) for 1, 2, 4, 8, 16, 32 concurrent
> MARK> sessions.
>
> MARK> ------------
>
> MARK> This tests many binaries including 5.0.37 with the v2 Google patch (aka 5037v2).
> MARK> On a configuration I no longer have access to, 5037v2 had a severe performance
> MARK> regression from code in the SHOW [TABLE|USER|_STATISTICS patch. The regression
> MARK> was caused by mutex contention. The result on my current platform is
> MARK> much less severe,
> MARK> but you can see the impact in simple-allcols and simple-handler listed below
> MARK> -- compare 5037, 5037v2 and 5037v4.
>
> MARK> I am using glibc 2.5 now and used an older glibc version in the past. I am
> MARK> curious if pthread code is that much better on my current platform.
>
> MARK> I thought that the Maria version of that feature would inherit this performance
> MARK> problem. Performance loss in Maria is 5% to 10% with userstat enabled for
> MARK> high levels of concurrency -- again see results for simple-allcols and
> MARK> simple-handle -- and this is much less than the loss in 5037v2, but more
> MARK> than the loss in 5037v4 which had fixes for user and table stats code.
>
> Thanks a lot for the numbers!
> Shows just that things are as you suspected.
>
> MARK> oltp-ro
> MARK>   1         2           4         8         16       32
> MARK> concurrent_sessions / binary
>
> <cut>
>
> MARK> 780     1362    2590    4287    4193    4096    5138pi
> MARK> 703     1425    2593    4379    4176    4110    maria.nostat
> MARK> 684     1281    2439    4064    3896    3882    maria.stat

oltp-ro run again for maria.nostat
                 761     1278    2593    4406    4207    4164    maria.nostat
>
> <cut>
>
> MARK> simple-allcols
> MARK>   1         2           4           8           16         32
> MARK> concurrent_sessions / binary
>
> <cut>
>
> MARK> 14797   24481   48254   92323   87722   86436   5138pi
> MARK> 13418   24980   49777   94425   88083   86854   maria.nostat
> MARK> 13062   23378   46636   83449   77714   77245   maria.stat

simple-allcols re-run for maria.nostat
                12024   23891   50433   93778   88210   86127   maria.nostat

So it looks like the regression at --num_threads==1 is real.

I am trying without success to get oprofile results for maria.nostat.
I have them for 5138pi. I don't know why I can't get them for maria --
configure and compiler options appear to be the same, symbols appear
to be there, ... bizarre.

>
> Do you have any explanation why maria.nostat would be slower than
> 5138pi ?
>
> I can't think of anything in MariaDB that could cause that kind of
> overhead, especially if 5138pi is running with userstats enabled.

5138pi is not running with userstats enabled. It is 5.1.38 + InnoDB
1.0.4 plugin with a few patches.

-- 
Mark Callaghan
mdcallag@xxxxxxxxx