首页 > 代码库 > innodb buffer pool

innodb buffer pool

 

add page to flush list

buffer pool中的page,有三种状态:

l  free:      当前page未被使用

l  clean:    当前page被使用,对应于数据文件中的一个页面,但是页面未被修改

l  dirty:     当前page被使用,对应于数据文件中的一个页面,同时页面被修改

free类型的page,一定位于buf pool的free链表中。

clean,dirty两种类型的page,一定位于buf pool的LRU链表中。(LRU:近期最少使用)

与此同时,dirty page还位于buf pool的flush链表中。flush list中的dirty page,按照page的oldest_modificattion时间排序,oldest_modification越大,说明page修改的时间越晚,就排在flush 链表的头部;oldest_modification越小,说明page修改的时间越早,就排在flush链表的尾部。当InnoDB进行flush list的flush操作时,从flush list链表的尾部开始,写出足够数量的dirty pages,推进Checkpoint点,保证系统的恢复时间。

dirty page越新的,排在头部;越老的,排在尾部。

将比较老的数据,写出去。

 

那么,dirty page是在什么时候进入flush list的呢?看过我以前文档的同学,一定知道InnoDB存储引擎有一个所谓的mini-transaction,页面访问/修改都被封装为一个mini-transaction,当mini-transactin提交的时候,也就是该mini-transaction修改的页面进入flsuh list的时候。

 

remove page from flush list

有两种操作,可以将dirty page从flush list中移除。一是LRU list flush;二是Flush list flush。

 

Buffer Pool LRU/Flush List flush对比

总结来说,Flush lish flush与LRU list flush有以下几个不同之处:

LRU list flush,由用户线程触发(MySQL 5.6.2之前);而Flush list flush由MySQL数据库InnoDB存储引擎后台srv_master线程处理。(在MySQL 5.6.2之后,都被迁移到page cleaner线程中)

 

LRU list flush,其目的是为了写出LRU 链表尾部的dirty page,释放足够的free pages,当buf pool满的时候,用户可以立即获得空闲页面,而不需要长时间等待;Flush list flush,其目的是推进Checkpoint LSN,使得InnoDB系统崩溃之后能够快速的恢复。

 

LRU list flush,其写出的dirty page,需要移动到LRU链表的尾部(MySQL 5.6.2之前版本);或者是直接从LRU链表中删除,移动到free list(MySQL 5.6.2之后版本)。Flush list flush,不需要移动page在LRU链表中的位置。

 

LRU list flush,由于可能是用户线程发起,已经持有其他的page latch,因此在LRU list flush中,不允许等待持有新的page latch,导致latch死锁;而Flush list flush由后台线程发起,未持有任何其他page latch,因此可以在flush时等待page latch。

 

LRU list flush,每次flush的dirty pages数量较少,基本固定,只要释放一定的free pages即可;Flush list flush,根据当前系统的更新繁忙程度,动态调整一次flush的dirty pages数量,量更大。

 

Buffer Pool Usage Limitations

此章节记录Buffer Pool的各种使用缺陷,及不同版本的优化策略。

Drop Table

在Mark Callaghan的最新一篇博文:Stalls during DDL中[6](备注:mysqlops网站上也有相关文章分析这个严重问题,链接地址:http://www.mysqlops.com/2012/04/01/mysql-innodb-file-per-table.html),其提到InnoDB存储引擎在进行Drop Table操作时,会短暂hang住整个系统,而且这个hang的时间的长短与Buffer Pool的大小相关。主要原因在于InnoDB在drop table时,会连续两次遍历buf pool LRU 链表,遍历的过程加锁,因此导致系统hang住。那么MySQL数据库InnoDB存储引擎在drop table时为何需要遍历LRU链表呢?

// 1. 从LRU链表尾部开始遍历

// 2. 对于每一个属于Drop Table的page,判断page中是否有项进入

//      adaptive hash,若有,则收集当前page

// 3. 收集到1024个这样的page后,释放buf pool mutex,集中调用函数

//      buf_LRU_drop_page_hash_batch,释放page在adaptive hash中的项

// 4. 重新获取buf pool mutex,继续遍历buf pool LRU 链表,直至链表头

// 5. 最终,是否buf pool mutex,退出

// 再次遍历buf pool LRU 链表,释放所有drop table对应的page

buf_LRU_invalidate_tablespace_buf_pool_instance();

// 简要的处理流程描述:

// 1. 获取buf pool mutex

// 2. 遍历buffer pool LRU链表

// 3. 若为dirty page,则将dirty page设置为clean page,并从flush list中移除

// 4. 将page从LRU list中移除,并且添加入free list

// 5. 最后,释放buf pool mutex

 

总结:

l  确实需要遍历两遍buf pool LRU 链表

一遍用于释放adaptive hash中的记录;二遍是用于释放page。

l  第一遍遍历LRU链表,会定期释放buf pool mutex,因此对于系统hang的影响较小;而第二遍会一直持有,对系统hang的影响较大。

 

innodb buffer pool