MySQL - InnoDB特性 - Buffer Pool漫谈

ゝ一世哀愁。 2022-01-15 05:41 222阅读 0赞

[为什么80%的码农都做不了架构师？>>> ][80_]  ![hot3.png][]

缓存管理是DBMS的核心系统，用于管理数据页的访问、刷脏和驱逐；虽然操作系统本身有page cache，但那不是专门为数据库设计的，所以大多数数据库系统都是自己来管理缓存。由于几乎所有的数据页访问都涉及到Buffer Pool，因此buffer pool的并发访问控制尤为重要，可能会影响到吞吐量和响应时间，本文主要回顾一下MySQL的buffer Pool最近几个版本的发展(若有遗漏，欢迎评论补充), 感受下最近几年这一块的进步

### **MySQL5.5之前** ###

只能设置一个buffer pool, 通过innodb\_buffer\_pool\_size来控制, 刷脏由master线程承担，扩展性差。

### **MySQL 5.5** ###

引入参数innodb\_buffer\_pool\_instances，将buffer pool拆分成多个instance，从而减少对buffer pool的访问控制，这时候的刷脏还是由Master线程来承担。

### **MySQL 5.6** ###

引入了buffer Pool page Id转储和导入特性，也就是说可以随时把内存中的page no存下来到文件里，在重启时会自动把这些Page加载到内存中，使内存保持warm状态. 此外该版本第一次引入了page cleaner,将flush list/lru上的刷脏驱逐工作转移到单独线程，减少了master线程的负担

### **MySQL 5.7** ###

这个版本发布了一个重要特性：online buffer pool resize. 当然是否是online需要打一个问号，因为在resize的过程中需要拿很多全局大锁，在高负载场景下很容易导致实例Hang住([81615][])。   
和之前不同，buffer pool被分成多个instance，每个instance又由多个chunk组成，每个chunk的大小受到参数innodb\_buffer\_pool\_chunk\_size控制，默认128MB, buffer pool resize都是以chunk为单位增加或减少的。  
另外一个需要注意的点是：你配置的Buffer Pool Size可能比你实际使用的内存要大，尤其对于大Bp而言，这是因为内部做了对齐处理, buffer pool size必须以 innodb\_buffer\_pool\_chunk\_size \* innodb\_buffer\_pool\_instances来做向上对齐([80350][])

我们知道通常数据文件的IO都被设置成O\_DIRECT, 但每次修改后依然需要去做fsync，来持久化元数据信息，而对于某些文件系统而言是没必要做fsync的，因此加入了新选项O\_DIRECT\_NO\_FSYNC，这个需求来自于facebook. 他们也对此做了特殊处理：除非文件size变化，否则不做fsync。（最近在buglist上对这个参数是否安全的讨论也很有意思，官方文档做了新的说明，感兴趣的可以看看 \[94912:O\_DIRECT\_NO\_FSYNC possible write hole  
\]([https://bugs.mysql.com/bug.php?id=94912)][https_bugs.mysql.com_bug.php_id_94912]）

再一个重要功能是终于引入了multiple page cleaner, 可以多个后台线程并发刷脏页，提供了更好的刷脏性能，有效避免用户线程进入single page flush。当然这还不够完美，主要有四点：

1.  用户线程依然会进入single page flush，而一旦大量线程进入，就会导致严重性能下降：超频繁的fsync，激烈的dblwr竞争，线程切换等等
2.  当redo空间不足时，用户线程也会进入page flush，这在高负载场景下是很常见的，你会发现系统运行一段时间后，性能急剧下降。这是因为redo产生太快，而page flush又跟不上，导致checkpoint无法推进。那么用户线程可能就要过来做fuzzy checkpoint了。那时候性能基本上没法看了。
3.  dblwr成为重要的单点瓶颈。 如果你的服务器不支持原子写的话，必须打开double write buffer。写入Ibdata一段固定区域，这里是有锁包含的，区分为两部分：single page flush和batch flush, 但无论如何，即使拆分了多个page cleaner，最终扩展性还是受限于dblwr
4.  没有专用的lru evict线程，都是Page cleaner键值的。举个简单的例子，当buffer pool占满，同时又有很多脏页时，Page cleaner可能忙于刷脏，而用户线程则得不到free page，从而陷入single page flush

如果你对上述几个问题极不满意，可以尝试percona server, 他们向来擅长优化Io bound场景的性能，并且上述几个问题都解决了，尤其是dblwr，他们做了多分区的改进。

### **MySQL 8.0** ###

增加了一个功能，可以在实例宕机时，core文件里不去掉buffer pool, 这大大减少了core文件的大小。要知道，很多时候实例挂是因为文件损坏，不停的core重启会很快把磁盘占满，你可以通过设置参数innodb\_buffer\_pool\_in\_core\_file来控制。

另外8.0最重要的一个改进就是：终于把全局大锁buffer pool mutex拆分了，各个链表由其专用的mutex保护，大大提升了访问扩展性。实际上这是由percona贡献给上游的，而percona在5.5版本就实现了这个特性([WL\#8423: InnoDB: Remove the buffer pool mutex][WL_8423_ InnoDB_ Remove the buffer pool mutex] 以及 [bug\#75534][bug_75534])。

原来的一个大mutex被拆分成多个为free\_list, LRU\_list, zip\_free, 和zip\_hash单独使用mutex:

- LRU_list_mutex for the LRU_list;
      - zip_free mutex for the zip_free arrays;
      - zip_hash mutex for the zip_hash hash and in_zip_hash flag;
      - free_list_mutex for the free_list and withdraw list.
      - flush_state_mutex for init_flush, n_flush, no_flush arrays.

由于log system采用lock-free的方式重新实现，flush\_order\_mutex也被移除了，带来的后果是flush list上部分page可能不是有序的，进而导致checkpoint lsn和以前不同，不再是某个log record的边界，而是可能在某个日志的中间，给崩溃恢复带来了一定的复杂度（需要回溯日志）

log\_free\_check也发生了变化，当超出同步点时，用户线程不再自己去做preflush，而是通知后台线程去做，自己在那等待(`log_request_checkpoint`), log\_checkpointer线程会去考虑`log_consider_sync_flush`，这时候如果你打开了参数`innodb_flush_sync`的话, 那么flush操作将由page cleaner线程来完成，此时page cleaner会忽略io capacity的限制，进入激烈刷脏

8.0还增加了一个新的参数叫innodb\_fsync\_threshold，，例如创建文件时，会设置文件size,如果服务器有多个运行的实例，可能会对其他正常运行的实例产生明显的冲击。为了解决这个问题，从8.0.13开始，引入了这个阈值，代码里在函数`os_file_set_size`注入，这个函数通常在创建或truncate文件之类的操作时调用，表示每写到这么多个字节时，要fsync一次，避免对系统产生冲击。这个补丁由facebook贡献给上游。

### **其他** ###

当然也有些辅助结构来快速查询buffer pool:

*  adaptive hash index: 直接把叶子节点上的记录索引了，在满足某些条件时，可以直接定位到叶子节点上，无需从根节点开始扫描，减少读的page个数
 *  page hash: 每个buffer pool instance上都通过辅助的page hash来快速访问其中存储的page，读加s锁，写入新page加x锁。page hash采用分区的结构，默认为16，有一个参数innodb\_page\_hash\_locks，但很遗憾，目前代码里是debug only的，如果你想配置这个参数，需要稍微修改下代码，把参数定义从debug宏下移出来
 *  change buffer: 当二级索引页不在时，可以把操作缓存到ibdata里的一个btree(ibuf)中，下次需要读入这个page时，再做merge；另外后台master线程会也会尝试merge ibuf。

最后，听说官方正在努力解决double write buffer的瓶颈问题，期待一下.

作者：zhaiwx\_yinfeng

[原文链接][Link 1]

本文为云栖社区原创内容，未经允许不得转载。

转载于:https://my.oschina.net/yunqi/blog/3043811

[80_]: https://my.oschina.net/u/2663968/blog/3051541
[hot3.png]: /images/20220115/7c722bf09a8c4591aa04bd7e28053a61.png
[81615]: https://bugs.mysql.com/bug.php?id=81615
[80350]: https://bugs.mysql.com/bug.php?id=80350
[https_bugs.mysql.com_bug.php_id_94912]: https://bugs.mysql.com/bug.php?id=94912%29
[WL_8423_ InnoDB_ Remove the buffer pool mutex]: https://dev.mysql.com/worklog/task/?id=8423
[bug_75534]: https://bugs.mysql.com/bug.php?id=75534
[Link 1]: https://yq.aliyun.com/articles/700436?utm_content=g_1000055056