← Back to team overview

maria-developers team mailing list archive

Re: impact of segmented table_open_cache on sysbench results

 

On Fri, Mar 15, 2013 at 3:50 PM, Axel Schwenke <axel@xxxxxxxxxxxx> wrote:

> Hi Mark,
>
> MARK CALLAGHAN wrote:
>
> > I didn't see a big change in going from toci=1 to toci=64. I don't
> > dispute your results, but I am curious about why it made a difference
> > for you but not for me. My sysbench test had:
> > * 8 tables, partitioning not used
> > * 8 copies of the sysbench process (1 per table), running a different
> > host from mysqld
> > * mysqld on host with 12 real CPUs and 24 vCPUs after HT was enabled
> > * jemalloc
> > * my table names were test.sbtestX (for X in 1 .. 8)
>
> I see. It seems you are using sysbench-0.4. I migrated to sysbench-0.5 (the
> bzr trunk) a while ago because it has
>
> a) LUA support, this is great to implement custom workloads, and
> b) the ability to report progress; this is useful to spot irregularities
> like write stalls
>

I want to upgrade too but right now my scripts depend on 0.4 and I have my
own 0.4 fork that has very good result reporting per-interval that makes it
easy to find stalls.

>
> This is a pure read only benchmark, so fsync does not matter. Also I have
> found that the InnoDB plugin is ~5-10% faster than XtraDB for sysbench.
> Hence the last benchmarks are using plain InnoDB.
>
>
I will revisit this for my read-only tests. I think I was looking at it for
update-only tests.

-- 
Mark Callaghan
mdcallag@xxxxxxxxx

References