数据库内核月报

数据库内核月报 - 2019 / 07

MySQL · 引擎特性 · Buffer Pool 漫谈

Author: weixiang

缓存管理是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 poss

再一个重要功能是终于引入了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 以及 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的瓶颈问题,期待一下.