Category Archives: Performance
Recently we had a report from a user who had seen a stunning 90% performance regression after upgrading his server to a Linux kernel with KPTI (kernel page-table isolation – a remedy for the Meltdown vulnerability). (more…) …
Continue reading “MyISAM and KPTI – Performance Implications From The Meltdown Fix”
When you have read my previous blog post about MariaDB 10.1 GA performance, you have probably wondered why I didn’t include any numbers for MySQL 5.7. There are two reasons: first MySQL wasn’t GA at that time and secondly MySQL is not running stable on Power8.
Today I will come up with a comparison benchmark. I have chosen some more down-to-earth hardware for that because that is what the majority of our users will be running. Specifically it’s a SP-64 cloud machine from OVH. It has a 4-core Intel CPU and 64G of RAM. Disks aren’t fancy, but the benchmark is again a simplified read-only OLTP workload that runs from memory. …
Continue reading “MariaDB 10.1 and MySQL 5.7 performance on commodity hardware”
MariaDB 10.1 not only contains tons of new features, it has also been polished to deliver top performance. The biggest improvement has been achieved for scalability on massively multithreaded hardware.
(more…) …
Continue reading “MariaDB 10.1 can do 1 million queries per second”
It’s been almost a year since I benchmarked MariaDB and MySQL on our good old 4 CPU / 32 Cores / 64 Threads Sandy Bridge server. There seem to be a few interesting things happened since that time.
- MySQL 5.6.23 peak throughput dropped by ~8% compared to 5.6.14. Looks like this regression appeared in MySQL 5.6.21.
- 10.0.18 (git snapshot) peak threads increased by ~20% compared to 10.0.9 and reached parity with 5.6.23 (not with 5.6.20 though).
- 10.1.4 (git snapshot) and 5.7.5 are the champions (though 10.1.4 was usually 1-5% faster). Both have similar peaks @ 64 threads.
…
Continue reading “A few interesting findings on MariaDB and MySQL scalability, multi-table OLTP RO”
Introduction
Evaluating the performance of database systems is a very demanding task. There are a lot of hard choices to be made, e.g.:
- What operating system and operating system version is to be used
- What configuration setup is to be used
- What benchmarks are to be used and how long are the warm-up and measure times
- What test setups are to be used
- What version of the database management system is used
- What storage engine is used
While performance evaluation is mostly machine time, there is still a lot of hard work for the human monitoring the tests. …
Continue reading “Performance evaluation of MariaDB 10.1 and MySQL 5.7.4-labs-tplc”
This is a follow-up on my previous blog post about using Lua enabled sysbench. Today I will dive into how to write Lua scripts for sysbench. (more…) …
A quite common benchmark for MySQL is sysbench. It was written nearly 10 years ago by Alexey Kopytov.
Sysbench has modes to benchmark raw CPU performance, mutex speed, scheduler overhead and file IO performance. The probably most often used sysbench mode is OLTP. This benchmark mimics a OLTP scenario with small transactions hitting an optimized database. There are many variables to play with, most important is the number of simulated application threads (option –num-threads). The OLTP benchmark can be run read-only, then it does 14 SELECT queries per transaction. Or it can be run read-write which adds 2 UPDATEs and one INSERT and DELETE. …
Back when the first version of the MariaDB Java Client was released, someone asked in the comments about the performance characteristics of the driver compared to ConnectorJ. I answered with hand-waving, saying that nobody does anything stupid, the performance of the drivers would be roughly the same, but I promised to measure it and tell the world one day. And now that day has come. The day where three MySQL JDBC drivers (ConnectorJ, MariaDB JDBC, and Drizzle JDBC) are compared against each other. Unlike the server, which gets benchmarking attention all the time, there is no standard benchmark for connectors, so I needed to improvise, while trying to keep the overhead of the server minimal. …