Category Archives: Performance
We recently had a chance to test how the Shannon Direct-IO PCIe Flash G3i devices improves the performance of MariaDB. Anybody who cares about I/O performance has noticed that PCIe drives have become readily available in recent years and that they are significantly faster than normal SSD drives connected to the traditional SATA port (not to mention hard disk drives). In addition to being great hardware, the Shannon drives offer an extra boost by having a device driver that supports atomic writes. This means the device guarantees that a write made to it reaches the drive, and thus the MariaDB server does not have to run extra checks like it does on normal hardware.
…
Continue reading “Improved MariaDB performance using Shannon Systems PCIe and atomic writes”
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. …