网易视频云：MYSQL-5.5-和-5.6的IO控制简单分析(二).

网易视频云：MYSQL5.5和5.6的IO控制简单分析（二）网易视频云接着上一篇分享，与大家分享一下MYSQL5.5和5.6的IO控制简单分析（二）。MYSQL5.6.7RC相对于5.5版本来说，5.6在adaptiveflush的算法上有非常大的改变。相对于5.5的不同之处如下：前台线程会刷脏页，调用buf_flush_single_page_from_LRU,从LRU链表尾部刷一个页面有一个单独的线程buf_flush_page_cleaner_thread在完成刷脏页的任务该线程有一个while循环，一个循环基本是1秒钟，这是INNODB主要的IO控制流程1．当检测到系统idle或者没有pendingIO，无事可做时，会sleep一直到next_loop_time。（目的是为保证有前台活动时，脏页能控流刷出，而一旦前台没有活动时，脏页能迅速以100%IO快速刷出）if(srv_check_activity(last_activity)||buf_get_n_pending_read_ios()||n_flushed==0){page_cleaner_sleep_if_needed(next_loop_time);}2．如果检测到系统有活动a)刷一次LRU链表尾部调用page_cleaner_flush_LRU_tail()b)再刷一次flush链表调用page_cleaner_flush_pages_if_needed()3．否则a)以100%系统IO能力刷一次flushList当系统关闭时，持续以100%IO能力刷脏页刷LRU流程：整个流程被打散到一个个小的chunk中，防止一次锁定LRU链表过长时间。一次搜索的深度最长为1024个页面，一个chunk的大小设定为100page_cleaner_flush_LRU_tail-buf_flush_LRU-buf_flush_batch-buf_do_LRU_batch1.先根据unzipLRU链表刷未压缩的页面a)当buf的free链表长度小于1024，并且未压缩的LRU链表长度大于整个LRU链表长度的1/10，才刷2.如果未够100个页面则再根据LRU链表刷一次，刷够100为止a)Buf的free链表小于1024，并且LRU链表长度大于256才刷页面刷FLUSHLIST流程：page_cleaner_flush_pages_if_needed-page_cleaner_do_flush_batchAdaptiveFlush控流算法相对复杂：1.首先每30个循环（一般是一秒一循环）计算一个日志产生平均速率和刷脏页平均速率。这里不再像5.5的流式统计算法，这里是以30个循环作一个batch，只有在跨batch时才会丢弃之前的信息。2.获取bufpool中最老的dirtiedLSN，跟据当前lsn和这个最老的dirtiedlsn相减得到age3.计算脏页比率a)先得到系统脏页占buffer的比率pct_for_dirtyi.有一个记录最大脏页比率的lowwatermark默认50%ii.如果lowwatermark为0（没有设置），那么如果内存脏页率超过75返回100%iii.如果当前内存脏页率超过lowwatermark，返回dirty_pct*100/75，b)根据age计算lsn比率pct_for_lsn（非常复杂的公式，估计是实验调优）i.有一个记录adaptiveflush的lowwatermark，默认10%ii.记录af_lwm=lowwatermark*logcapacity/100iii.如果ageaflwm则返回0iv.获取max_async_age为当前max_modified_age_async值（此值用于判断，当超过此值，系统起预刷buffpool）v.如果没有到这个值，并且没开启adaptiveflish，也返回0vi.获取lsn_age_factor=age*100/max_modified_age_async值vii.返回(Max_io_capacity/io_capacity)*(lsn_age_factor*sqrt(lsn_age_factor))/7.54.获取pct_total为pct_for_dirty和pct_for_lsn的较大值。5.根据pct_total算出来的io量，和之前30秒算出来的avg_page_rate做一个平均值，再和系统的max_io_capacity算一个较小值赋值为n_page6.根据当前lsn和上一次计算的lsn还有lsn产生的平均速度计算一个age_factor7.根据算出来的要刷的脏页n_page和age_factor乘以平均lsn产生速率传递给刷脏页的主函数page_cleaner_do_flush_batch总结：5.5的脏页flush分布在不同的线程中（LRUFlush在前台线程，DirtyFlush在后台线程），后台线程的DirtyFlush利用流式的IO信息统计来估算后台线程需要刷的页面数，由于需要实时统计LRUFLUSH的页面数，而它们又由其他线程完成，因此不可能很精确的控制当前时间需要DirtyFlush的页面数，而且多线程的并发写页面也会造成IO不稳定的现象。5.6将主要的刷脏页任务集中在一个后台线程，前台线程一次最多刷一个页面，因此一个线程能做到更加精确的IO控制。除此之外，改进的AdaptiveFlush引入了一个日志age的统计维度，能够更精确的计算需要刷写的脏页量最后，说一下自己的感想，一个表现稳定的IO算法必然需要大量的实验然后根据实验的结果进行参数调整，MYSQL每个大版本对IO的改动都非常大。IO控制算法也都有改进。在代码中部分参数可能让人摸不着头脑，但这些必定都是大量实践的结果。仔细分析和耐心测试才是系统级软件控制IO控制性能的唯一方法。