April 19, 2014

kernel_mutex problem cont. Or triple your throughput

This is to follow up my previous post with kernel_mutex problem. First, I may have an explanation why the performance degrades to significantly and why innodb_sync_spin_loops may fix it. Second, if that is correct ( or not, but we can try anyway), than playing with innodb_thread_concurrency also may help. So I ran some benchmarks with […]

Effect from innodb log block size 4096 bytes

In my post MySQL 5.5.8 and Percona Server: being adaptive I mentioned that I used innodb-log-block-size=4096 in Percona Server to get better throughput, but later Dimitri in his article MySQL Performance: Analyzing Percona’s TPCC-like Workload on MySQL 5.5 sounded doubt that it really makes sense. Here us quote from his article: “Question: what is a […]

MySQL 5.5.8 and Percona Server: being adaptive

As we can see, MySQL 5.5.8 comes with great improvements and scalability fixes. Adding up all the new features, you have a great release. However, there is one area I want to touch on in this post. At Percona, we consider it important not only to have the best peak performance, but also stable and predictable performance. I refer you […]

SSD, XFS, LVM, fsync, write cache, barrier and lost transactions

We finally managed to get Intel X25-E SSD drive into our lab. I attached it to our Dell PowerEdge R900. The story making it running is worth separate mentioning – along with Intel X25-E I got HighPoint 2300 controller and CentOS 5.2 just could not start with two RAID controllers (Perc/6i and HighPoint 2300). The […]

Linux schedulers in tpcc like benchmark

I mentioned earlier that IO scheduler CFQ coming by default in RedHat / CentOS 5.x may be not so good for MySQL. And yesterday one customer reported that just changing cfq to noop solved their InnoDB IO problems. I ran tpcc scripts against XtraDB on our Dell PowerEdge R900 server (16 cores, 8 disks in […]

Fix of InnoDB/XtraDB scalability of rollback segment

Recently I wrote about InnoDB scalability on 24-core box, and we made research of scalability problems in sysbench write workload (benchmark emulates intensive insert/delete queries). By our results the problem is in concurrency on rollback segment, which by default is single and all transactions are serialized accessing to segment. Fortunately InnoDB internally has mechanism to […]

XtraDB/InnoDB CPU bound benchmarks on 24cores server

One of our customers gave me a chance to run some benchmarks on 24-core (intel cpu based) server, and I could not miss it and ran few CPU-bound tasks there. The goal of benchmarks was investigation of InnoDB-plugin and XtraDB scalability in CPU-bound load.

MySQL QA Team Benchmarks for MySQL 5.1.30

As you might have seen MySQL QA Team has published their benchmarks for MySQL 5.0.72 and 5.1.30. It is interesting to compare with results I posted previously

InnoDB thread concurrency

InnoDB has a mechanism to regulate count of threads working inside InnoDB. innodb_thread_concurrency is variable which set this count, and there are two friendly variables innodb_thread_sleep_delay and innodb_concurrency_tickets. I’ll try to explain how it works. MySQL has pluginable architecture which divides work between mysql common code (parser, optimizer) and storage engine. From storage engine’s point […]

Mess with innodb_thread_concurrency

In MySQL 5.0.19 the meaning of innodb_thread_concurrency variable was changed (yeah, again). Now innodb_thread_concurrency=0 means unlimitied count of concurrent threads inside InnoDB. It’s logical, but there was long way. In MySQL versions below 5.0.8 for unlimited threads you had to set innodb_thread_concurrency over 500 (and default value for innodb_thread_concurrency was 8 ). Starting with MySQL […]