September 16, 2014

InnoDB adaptive flushing in MySQL 5.6: checkpoint age and io capacity

In MySQL 5.6 InnoDB has a dedicated thread (page_cleaner) that’s responsible for performing flushing operations. Page_cleaner performs flushing of the dirty pages from the buffer pool based on two factors: – access pattern  -  the least recently used pages will be flushed by LRU flusher from LRU_list when buffer pool has no free pages anymore; […]

Adaptive flushing in MySQL 5.6 – cont

This is to continue my previous experiments on adaptive flushing in MySQL 5.6.6. Now I am running Ubuntu 12.04, which seems to provide a better throughput than previous system (CentOS 6.3), it also changes the profile of results. So, as previous I run tpcc-mysql 2500W, against MySQL 5.6.6 with innodb_buffer_pool_size 150GB, and now I vary […]

Adaptive flushing in MySQL 5.6

As you may know, flushing in MySQL is an area of my interest, I wrote about it several times, i.e. http://www.percona.com/blog/2011/09/18/disaster-mysql-5-5-flushing/ http://www.percona.com/blog/2011/03/31/innodb-flushing-a-lot-of-memory-and-slow-disk/ http://www.percona.com/blog/2011/01/03/mysql-5-5-8-in-search-of-stability/ In MySQL 5.6 there was implemented a new flushing logic, so I decided to check what do we have now.

Effect of adaptive_flushing

I recently had the chance to witness the effects of innodb_adaptive_flushing on the performance of InnoDB Plugin 1.0.5 in the wild, which Yasufumi wrote about previously here and here. The server in question was Solaris 10 with 8 disk RAID10 and 2 32GB SSDs used for ZIL and L2ARC, 72G RAM and 40G buffer pool. […]

Disaster: MySQL 5.5 Flushing

We raised topic of problems with flushing in InnoDB several times, some links: InnoDB Flushing theory and solutions MySQL 5.5.8 in search of stability This was not often recurring problem so far, however in my recent experiments, I observe it in very simple sysbench workload on hardware which can be considered as typical nowadays.

InnoDB Flushing: a lot of memory and slow disk

You may have seen in the last couple of weekly news posts that Baron mentioned we are working on a new adaptive flushing algorithm in InnoDB. In fact, we already have three such algorithms in Percona Server (reflex, estimate, keep_average). Why do we need one more? Okay, first let me start by showing the current […]

Different flavors of InnoDB flushing

In my recent benchmarks, such as this one about the Virident TachIon card, I used different values for innodb_buffer_pool_size, like 13GB, 52GB, and 144GB, for testing the tpcc-mysql database with size 100G. This was needed in order to test different memory/dataset size ratios. But why is it important, and how does it affect how InnoDB works […]

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 […]

Why delayed flushing can result in less work

I can think of at least two major reasons why systems delay flushing changes to durable storage: 1. So they can do the work when it’s more convenient. 2. So they can do less work in total. Let’s look at how the second property can be true.

Which adaptive should we use?

As you may know, InnoDB has 2 limits for unflushed modified blocks in the buffer pool. The one is from physical size of the buffer pool. And the another one is oldness of the block which is from the capacity of transaction log files. In the case of heavy updating workload, the modified ages of […]