While the dataset on ext4 consumed 191GB, the lz4 compression of ZFS yielded a dataset of only 69GB. What is interesting is the amount of storage used. That essentially means if you configure ZFS properly, it can be as IO efficient as ext4. Any difference is within the margin of error. The results for both ext4 and ZFS are qualitatively similar. I have been a bit surprised by the results, enough to rerun the benchmarks to make sure. Then, at around 3000s the SSD Premium burst capacity is exhausted and the workload is only IO-bound. 256GB SSD Premium (SSD Premium LRS P15 – 1100 IOPS (3500 burst), 125 MB/s)īy default and unless specified, the ZFS filesystems are created with:ĭuring the initial 15 minutes, the buffer pool warms up but at some point, the workload shifts between an IO read bound to an IO write and CPU bound.2 vCpu, 32GB of Ram and 150GB of temporary storage.2 vCpu, 8GB of Ram and 75 GB of temporary storage.Since I am already familiar with AWS and Google cloud, I decided to try Azure for this project. The sysbench TPCC implementation was used. Furthermore, the dataset created by TPCC compresses rather well making it more realistic in the context of this post. A better compression ratio essentially means more data is cached and fewer IO operations will be needed.Ī well-known tool to benchmark a transactional workload is TPCC. The compressibility of the dataset is important since ZFS caches, the ARC and L2ARC, store compressed data. Such datasets don’t compress much, less than most real-world datasets I worked with. The classic sysbench MySQL database benchmarks have a dataset containing mostly random data. The big addition included in the 2.0 release is native encryption. ZFS 0.8.6-1 is not bleeding edge, there have been more than 1700 commits since and after 0.8.6, the ZFS release number jumped to 2.0. Between the two versions, there are in excess of 3600 commits adding a number of new features like support for trim operations and the addition of the efficient zstd compression algorithm. The present post is using version 0.8.6-1 of ZFS, the default one available on Debian Buster. In 2018, I reported ZFS performance results based on version 0.6.5.6, the default version available in Ubuntu Xenial. For all these reasons, I believe that it is time to revisit the performance aspect of MySQL on ZFS. Also, I found out the sysbench benchmark I used at the time was not a fair choice since the dataset it generates compresses much less than a realistic one. Since then, however, ZFS on Linux has progressed a lot and I also learned how to better tune it. At the time, ZFS was significantly slower than xfs and ext4 except when the L2ARC was used. As I published a few years ago, the argument for ZFS was less about performance than its useful features like data compression and snapshots. As some of you likely know, I have a favorable view of ZFS and especially of MySQL on ZFS.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |