广州知名的网站建设公司,关于用户网站建设的论文,如何在修改wordpress,10黄页网站建设转载自 MySQL - InnoDB特性 - Buffer Pool漫谈
缓存管理是DBMS的核心系统#xff0c;用于管理数据页的访问、刷脏和驱逐#xff1b;虽然操作系统本身有page cache#xff0c;但那不是专门为数据库设计的#xff0c;所以大多数数据库系统都是自己来管理缓存。由于几乎所有…转载自 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?id94912)
再一个重要功能是终于引入了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的瓶颈问题期待一下.
