Hi Kristian,
Kristian Nielsen wrote:
>
>> The poor performance of MySQL with 1 database is expected. However MySQL is
>> much better with 32 databases. Even better than MariaDB :(
>
> Ok, so I looked closer at the numbers (of which there were quite a few, thanks
> for doing this work :-). I have
Kristian Nielsen wrote:
> A couple of things that can be adjusted are --slave-domain-parallel-threads
> and --slave-parallel-max-queued. But I wouldn't expect them to have much
> effect on a sysbench load. If you want, you could try increase
> --slave-parallel-max-queued and set --slave-domain-par
Hi Kristian,
Am 25.03.2014 15:55, schrieb Kristian Nielsen:
> Axel Schwenke writes:
>
>> The poor performance of MySQL with 1 database is expected. However MySQL is
>> much better with 32 databases. Even better than MariaDB :(
>
> I haven't had time to go throug
Hi everybody,
here are some first results from my benchmarks of replication / group commit
performance.
The benchmark is sysbench OLTP rw, data set fitting in memory. I tested a
total of 27 configurations, 9 each for Maria-5.5.36, Maria-10.0.9 and
MySQL-5.6.16. Variations were for binlog on/off,
Moin Svoj,
Sergey Vojtovich wrote:
> Sergei pointed out that there is up to 10% slowdown in read-write benchmark at
> high concurrency. Could you share benchmark details, I'd like to debug it.
> Just pointers to build/run scripts on the benchmark server should be enough.
The benchmark was run on
Kristian Nielsen wrote:
> I implemented a simple program to generate some profile load:
>
> https://github.com/knielsen/gen_profile_load
I propose the following change to make it work with MariaDB releases before
10.0.4 (and MySQL) that lack the SHUTDOWN statement:
--- gen_profile_load.c.ori
Hi Kristian,
Kristian Nielsen wrote:
> I have been analysing CPU bottlenecks in single-threaded sysbench read-only
> load. I found that icache misses is the main bottleneck, and that
> profile-guided compiler optimisation (PGO) with GCC gives a large speedup, 25%
> or more.
>
> (More details in m
Hi,
for those of you who didn't attend the Barcelona meeting last week, here are
the plans for next steps in benchmarking:
1. top priority is automatic running of DBT3 for each new release of
MariaDB-10.0 and MySQL-5.6. Probably also for MariaDB-5.5. I'll send out
another mail to pinpoint DBT3 co
Hi Pavel,
Pavel Ivanov wrote:
>> From the above I'd say:
>> 911 928 - number of executed queries (1x LOCK_tdc per query)
>> 1 835 243 / 911 928= ~2 - LOCK_open was acquired 2x per query
>> 4 194 896 / 911 928= ~4 - LOCK_plugin was acquired 4x per query
>
> I wonder how the MariaDB under test was
Hi Sanja,
Oleksandr Byelkin wrote:
> 24.04.2013 19:00, Axel Schwenke пишет:
> [skip]
>>
>> OLTP ro transactions per second relative to glibc malloc
>> --
>> Threadsjemalloc-3.3.1glibc malloc
Hi,
Monty asked me to do a quick check how MariaDB performs with jemalloc. This
is in the light of the upcoming integration of TokuDB into the MariaDB tree.
TokuDB requires jemalloc.
While I did use tcmalloc in the connect speed benchmarks with good results,
I did no use jemalloc before. This art
Igor Babaev wrote:
> On 04/12/2013 09:00 AM, Axel Schwenke wrote:
>> Hi Igor, Timour,
>>
>> when I wrote the script to translate MariaDB table statistics to MySQL,
>> I found one problem. Imagine this simple table:
>>
>> create table t1 (c1 int, c2 int, c3 i
Hi,
here comes another followup. After having seen huge impact from performance
schema and the memory allocator, I started another run with optimal settings
and a reduced number of contestants. Montys working tree 10.0-monty was
added, that contains the latest optimizations.
The benchmark uses a
Axel Schwenke wrote:
> http://yoshinorimatsunobu.blogspot.fi/2012/12/non-persistent-connection-performance.html
> My results don't match Yoshis otherwise. See yourself.
OK, I found what makes the difference between Yoshis results and mine. It's
the performance schema. It d
Vladislav Vaintroub wrote:
>
> Historical remark on this, the patch for MDEV-3945,
> This patch was inspired by the said Yoshi's blog entry - he
> names holding lock during THD destructor (including freeing memory) as one
> of contention sources, and this was easy to fix. This patch made into
Axel Schwenke wrote:
> I did a similar benchmark.
I have pushed the scripts and raw results to the mariadb-benchmarks repo.
There are results for different engines.
mariadb-benchmarks/sysbench-runs/series22 = MyISAM
mariadb-benchmarks/sysbench-runs/series23 = InnoDB (my previous mail)
mari
Hi,
in the light of
http://yoshinorimatsunobu.blogspot.fi/2012/12/non-persistent-connection-performance.html
I did a similar benchmark. I used sysbench-0.4.12 for this with this command
line
$SYSBENCH --test=oltp --oltp-table-size=1000 --oltp-dist-type=uniform
--num-threads=$thread --oltp-read-o
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 p
18 matches
Mail list logo
