Mysql学习mysqldump造成Buffer Pool污染的研究

Mysql学习mysqldump造成Buffer Pool污染的研究,第1张

概述介绍《Mysql学习mysqldump造成Buffer Pool污染研究》开发教程,希望对您有用。

《MysqL学习MysqLdump造成Buffer Pool污染的研究》要点:
本文介绍了MysqL学习MysqLdump造成Buffer Pool污染的研究,希望对您有用。如果有疑问,可以联系我们。

前言:MysqL应用

最近Oracle MysqL在其官方Blog上贴出了 5.6中一些变量默认值的修改.其中innodb_old_blocks_time 的默认值从0替换成了1000(即1s)MysqL应用

关于该参数的作用摘录如下:MysqL应用

how long in milliseconds (ms) a block inserted into the old subList must stay there after its first access before it can be moved to the new subList. Increasing this value protects against the buffer pool being filled up by data that is referenced only for a brIEf period,such as during a full table scan.MysqL应用

其实作用就是:减小单次的大批量数据查询(类似于MysqLdump的行为)对于BufferPool(下称BP)的污染.MysqL应用

说到这里就不得不提一下BP的mIDpoint insert 机制.MysqL应用

下文就将对于这个机制做一定分析和讨论.
MysqL应用


一、 Buffer Pool 的insert 机制

BP可以被认为是一条长链表.被分成young 和 old两个部分,其中old默认占37%的大小(由innodb_old_blocks_pct 配置).靠近顶端的Page表示最近被放问.靠近尾端的Page表示长时间未被访问.而这两个部分的交汇处成为mIDpoint.每当有新的Page需要加载到BP时,该page都会被插入到mIDpoint的位置,并声明为old-page.当old部分的page,被访问到时,该page会被提升到链表的顶端,标识为young.MysqL应用

由于table scan的 *** 作是先load page,然后立即触发一次访问.所以当innodb_old_blocks_time =0 时,会导致table scan所需要的page不读的作为young page被添加到链表顶端.而一些使用较为不频繁的page就会被挤出BP,使得之后的sql会产生磁盘IO,从而导致响应速度变慢.这也就是标题中所提到的BP污染.MysqL应用

 MysqL应用

二、 修改innodb_old_blocks_time 的效果

percona之前也做过相关测试,其结论是time=0时,正常访问的吞吐量下降为10%;当time=1000时,吞吐量和没有备份时的性能一致.MysqL应用

是否真是如此呢,我们来亲自测试一下.MysqL应用

下面是测试结果:MysqL应用

其中concurrency代表sysbench中 --num-threads的数值.MysqL应用

OPT代表该环境下,没有MysqLdump时的sysbench QPS.MysqL应用

余下两列分别代表有MysqLdump时的sysbench QPS.MysqL应用

ConcurrencyOPTold_time=0old_time=1000
11739418362141
22970336703981
34734756836540
46471768058337
583551867615885
6993961297819893
71123301649126022
81266002384033346
91384683076039194
101503653903448925
111630534317460352
121749165206670180
131741606385378076
141737866516480661
151742687096590633
1617504480871102629
1717558390689103423
1817593994805112629
1917511493303120625

由结果可以看出,time=1000并没有给查询性能带来很大的提升.最佳情况下也只是比time=0时提高80%的性能.MysqL应用

为什么呢?MysqL应用

其实不难理解,表中的concurrency很大程度上决定了测试page的冷热程度.并发数越大,每面产生的并行请求就越多,从而每个page被访问的频率就越高,page在LRU链表中的位置也就越靠顶端.反之亦然.MysqL应用

那么我们来想想下高频率热点数据访问时的情况.这时虽然MysqLdump访问的page会不断加载在LRU顶端,但是高频度的热点数据访问会以更快的速度把page再次抢占到LRU顶端.从而导致MysqLdump加载入的page会被迅速刷下,并立即被evict(淘汰).因此,time=0或1000对这种压力环境下的访问不会造成很大影响,因为dump的数据根本抢占不过热点数据.MysqL应用

同样,超低频率的数据访问也是一样的情况.由于数据访问频度很低,大量的page都处于LRU链表的尾端.所以无论dump的page被加载到head或是mIDpoint位置,都会在热点数据的前面.也就是说无论怎样,数据page都会被淘汰.所以,这种压力环境下的性能同样不会随着time值的配置变化有很大浮动.MysqL应用

真正能够享受到time带来的福利的是那些 处于mIDpoint边缘的不温不火的数据.MysqL应用

从下图也可以看出,性能提升最大的情况集中在中等访问量的情况下,也即 37%的位置上


MysqL应用

三、 MID Point位置带来的影响

从之前的分析也可以得出这样的结论:innodb_old_blocks_time 的作用范围对page的冷热情况有直接联系.而innodb_old_blocks_pct 又决定了BP的数据分布.MysqL应用

那么 innodb_old_blocks_pct 的调节,能够左右 innodb_old_blocks_time的影响范围.MysqL应用

上图的曲线也证明了这样的观点.当innodb_old_blocks_pct 调节到60%时,波峰也相应平移到了 60%的位置.

总结:
1. innodb_old_blocks_time =1000 一定程度上可以降低MysqLdump类型的访问对数据库性能带来的影响.
2. innodb_old_blocks_time =1000 的优化效果有限,对于处于mIDpoint附近的page能带来最大的提升效果.MysqL应用

总结

以上是内存溢出为你收集整理的Mysql学习mysqldump造成Buffer Pool污染的研究全部内容,希望文章能够帮你解决Mysql学习mysqldump造成Buffer Pool污染的研究所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/sjk/1163131.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-06-01
下一篇 2022-06-01

发表评论

登录后才能评论

评论列表(0条)

保存