In addition to the problem with
trx_list scan we discussed in
Friday’s post, there is another issue in
InnoDB transaction processing that notably affects MySQL
performance – for every transaction InnoDB creates a …
One major problem in terms of MySQL
performance that still stands in the way of InnoDB scalability is
trx_list scan on consistent read view creation.
It was originally reported as a part of MySQL bug
#49169 and can be described as follows. Whenever a connection
wants to create a consistent read, it has to make a snapshot of
the transaction states to determine which transactions are seen
in the view later. To this …
Facebook is a major user of MySQL and has pushed the performance limits of the technology. Their MySQL experts have deep, hands on knowledge of the technology. I’m pleased to welcome Mark Callaghan, Software Engineer for Database Infrastructure at Facebook, back again this year to the …[Read more...]
I’m pleased to announce that Oracle is sending some of their top technical people to speak at the Percona Live MySQL Conference and Expo. The conference takes place April 22-25, 2013 at the Santa Clara Convention Center and Hyatt Santa Clara.
Tomas Ulin, VP, MySQL Engineering for Oracle, will present an invited keynote talk on “ …[Read more...]
Last time I wrote about memory allocators and how they can affect MySQL performance in general. This time I would like to explore this topic from a bit different angle: What impact does the number of processor cores have on different memory allocators and what difference we will see in MySQL performance in this scenario?
Let me share a conclusion first: If you have a server
with more than 8 cores you should use something different than
the default glibc memory allocator.
Investigating MySQL Replication Latency in Percona XtraDB Cluster
I was curious to check how Percona XtraDB Cluster behaves when it comes to MySQL replication latency — or better yet, call it data propagation latency. It was interesting to see whenever I can get stale data reads from other cluster nodes after write performed to some specific node. To test it I wrote quite a simple script (you can …[Read more...]
Based on a lot of surprising comments about my MySQL 5.5 vs 5.6 performance post I decided to perform deeper investigation to see where my results could go possibly wrong. I had set up everything to be as simple as possible to get maximally repeatable results. I did Read Only ran which is typically a lot more repeatable (though also less relevant for production like workload). I had done number of iterations for benchmark run and I used dedicated physical hardware box so external environment impact often causing problems in …[Read more...]
The idea to use SSD/Flash as a cache is not new, and there are
different solutions for this, both OpenSource like L2ARC for ZFS
and Flashcache from Facebook, and proprietary, like
directCache from Fusion-io.
They all however have some limitations, that’s why I am considering to have L2 cache on a database level, as an extension to InnoDB buffer pool.
Fortunately, there is a project in progress …
MySQL 5.6.7 RC is there, so I decided to test how it performs in
tpcc-mysql workload from both performance and stability
I can’t say that my experience was totally flawless, I bumped into two bugs:
But at the end, is not this why RC for? And …[Read more...]