MySQL - InnoDB特性 - Buffer Pool漫谈
缓存管理是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))
再一个重要功能是终于引入了multiple page cleaner, 可以多个后台线程并发刷脏页,提供了更好的刷脏性能,有效避免用户线程进入single page flush。当然这还不够完美,主要有四点:
- 用户线程依然会进入single page flush,而一旦大量线程进入,就会导致严重性能下降:超频繁的fsync,激烈的dblwr竞争,线程切换等等
- 当redo空间不足时,用户线程也会进入page flush,这在高负载场景下是很常见的,你会发现系统运行一段时间后,性能急剧下降。这是因为redo产生太快,而page flush又跟不上,导致checkpoint无法推进。那么用户线程可能就要过来做fuzzy checkpoint了。那时候性能基本上没法看了。
- dblwr成为重要的单点瓶颈。 如果你的服务器不支持原子写的话,必须打开double write buffer。写入Ibdata一段固定区域,这里是有锁包含的,区分为两部分:single page flush和batch flush, 但无论如何,即使拆分了多个page cleaner,最终扩展性还是受限于dblwr
- 没有专用的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的瓶颈问题,期待一下.
作者:zhaiwx_yinfeng
原文链接
本文为云栖社区原创内容,未经允许不得转载。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
分布式系统:CAP 理论的前世今生
CAP 理论是分布式系统设计中的一个重要理论,虽然它为系统设计提供了非常有用的依据,但是也带来了很多误解。本文将从 CAP 诞生的背景说起,然后对理论进行解释,最后对 CAP 在当前背景下的一些新理解进行分析,澄清一些对 CAP 的误解。 CAP 理论诞生的背景 CAP 理论的是在“数据一致性 VS 可用性”的争论中产生。CAP 的作者 Brewer 在 90 年代的时候就开始研究基于集群的跨区域系统(实质上是早期的云计算),对于这类系统而言,系统可用性是首要目标,因此他们采用了缓存或者事后更新的方式来优化系统的可用性。尽管这些方法提升了系统的可用性,但是牺牲了系统数据一致性。 Brewer 在 90 年代提出了 BASE 理论(基本可用、软状态、最终一致性),这在当时还不怎么被接受。因为大家还是比较看重 ACID 的优点,不愿意放弃强一致性。因此,Brewer 提出了 CAP 理论,目的就是为了开阔分布式系统的设计空间,通过“三选二”的公式,解放思想,不要只抓着一致性不放。 理解了 CAP 诞生的背景,我们才能更加深入的理解 CAP 理论,以及它带来的启示。“三选二”的观点虽然帮助大...
- 下一篇
最全的JAVA知识汇总(附讲解和思维导图)
微信公众号:内核小王子 关注可了解更多关于数据库,JVM内核相关的知识; 如果你有任何疑问也可以加我pigpdong[^1] jvm 一行代码是怎么运行的 首先,java代码会被编译成字节码,字节码就是java虚拟机定义的一种编码格式,需要java虚拟机才能够解析,java虚拟机需要将字节码转换成机器码才能在cpu上执行。 我们可以用硬件实现虚拟机,这样虽然可以提高效率但是就没有了一次编译到处运行的特性了,所以一般在各个平台上用软件来实现,目前的虚拟机还提供了一套运行环境来进行垃圾回收,数组越界检查,权限校验等。虚拟机一般将一行字节码解释成机器码然后执行,称为解释执行,也可以将一个方法内的所有字节码解释成机器码之后在执行,前者执行效率低,后者会导致启动时间慢,一般根据二八法则,将百分之20的热点代码进行即时编译。JIT编译的机器码存放在一个叫codecache的地方,这块内存属于堆外内存,如果这块内存不够了,那么JIT编译器将不再进行即时编译,可能导致程序运行变慢。 jvm如何加载一个类 第一步:加载,双亲委派:启动类加载器(jre/lib),系统扩展类加载器(ext/lib),应用类...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2全家桶,快速入门学习开发网站教程
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS7,CentOS8安装Elasticsearch6.8.6
- 2048小游戏-低调大师作品
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- Windows10,CentOS7,CentOS8安装Nodejs环境
- CentOS7安装Docker,走上虚拟化容器引擎之路