[MySQL 5.6] page cleaner线程的效率问题

最近在测试5.6.11的写性能，当我完成一项测试，关闭workload，习惯性设置innodb_max_dirty_pages_pct为0，然后等待脏页刷完再shutdown。

 

发现存在刷脏的抖动：

 

time      flushed    Innodb_data_written

11:49:57  3692        117.3m

11:49:58  1125        33.5m|

11:49:59  4187        134.6m

11:50:00  1241         35.0m

11:50:01  4076        127.4m

 

从pstack的采样结果来看，page cleaner线程频繁出现这样的backtrace。

buf_flush_page_cleaner_thread->page_cleaner_sleep_if_needed->os_thread_sleep

加了两个计数来监控，也发现page cleaner线程平均sleep时间过长（750,000 ms 左右）。

那么为什么会出现波动呢？

检查发现，机器上有一个heartbeat脚本每隔两秒钟更新一条记录。这会导致如下条件成立：

2385                 if (srv_check_activity(last_activity)

2386                     || buf_get_n_pending_read_ios()

2387                     || n_flushed == 0) {

2388                         page_cleaner_sleep_if_needed(next_loop_time);

2389                 }

 

srv_check_activity(last_activity) 为非0值。目前的判断太过粗糙了。一条简单的UPDATE 会造成page cleaner线程的巨大波动。

相应的问题，已经report到buglist上：http://bugs.mysql.com/bug.php?id=69174

好吧，对我而言办法比较土，临时的解决方案就是增加一个变量，来限制最大sleep时间，这样就可以获得一个平缓的刷脏频率：

time      flushed    Innodb_data_written

11:51:43   3971         120.6m

11:51:44   3987         124.6m

11:51:45   3859         124.6m

11:51:46   3992         121.0m

11:51:47   3855         120.7m

 

另外，当srv_check_activity(last_activity)返回非0值后，会走不同的逻辑：

2393                 if (srv_check_activity(last_activity)) {

2394                         last_activity = srv_get_activity_count();

2395

2396                         /* Flush pages from end of LRU if required */

2397                         n_flushed = buf_flush_LRU_tail();

2398

2399                         /* Flush pages from flush_list if required */

2400                         n_flushed += page_cleaner_flush_pages_if_needed();

 

buf_flush_LRU_tail() ： 依次遍历每个Buffer pool instance,从LRU尾部开始扫描，直到第srv_LRU_scan_depth个page停止，按批次刷LRU,每次期望刷100个page（一个CHUNK), 每个Bp会轮srv_LRU_scan_depth/100次循环

这里存在的问题，Mark Callaghan Report在这个Bug上：http://bugs.mysql.com/bug.php?id=69170

每一个CHUNK的循环，都是从LRU的尾部开始的，因为这中间会去释放bp的Mutex。

这样问题就比较明显了，如果有很多脏页，例如，我们假设LRU上的都是脏页.从函数buf_flush_LRU_list_batch的逻辑我们可以知道

1.如果这个Page是脏的，不可以替换，将其IO-FIX,并分发IO请求

2.回到LRU尾部，跳过IO-FIX的page，发发现新的脏页，同样将其IO-FIX，并返回到LRU尾部。

可以看到这里时间复杂度是O(N*N).当然如果是快速存储设备，可能在回到LRU尾部重新扫描时，之前IOFIX的page已经完成了IO，因此可以直接放到FreeList上。因此快速存储设备最优可以到达O(N)

按照Inaam的说法，5.6.12对此会有优化，拭目以待。另外在5.6.12中，可能会有很多sleep被替换成condition wait，希望这些能对写负载有帮助。