| 您的当前位置:首页 --> MYSQL教程 --> mysqldump造成Buffer Pool污染的研究 |
| MYSQL教程 mysqldump造成Buffer Pool污染的研究 |
| 浏览次数:1098 关键词 ( ) |
| 查看使用该CPU的产品 查看CPU天梯 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| CPU型号:mysqldump造成Buffer Pool污染的研究 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 主频:Ghz | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 睿频:Ghz | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 核心数:个 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 不支持超核心 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 制作工艺: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 插槽类型: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 功耗:0W | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| L3缓存:0MB | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 支持最大内存: 0GB | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| CPU详细参数 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
一、 Buffer Pool 的insert 机制BP可以被认为是一条长链表。被分成young 和 old两个部分,其中old默认占37%的大小(由 由于table scan的操作是先load page,然后立即触发一次访问。所以当innodb_old_blocks_time =0 时,会导致table scan所需要的page不读的作为young page被添加到链表顶端。而一些使用较为不频繁的page就会被挤出BP,使得之后的SQL会产生磁盘IO,从而导致响应速度变慢。这也就是标题中所提到的BP污染。
二、 修改innodb_old_blocks_time 的效果percona之前也做过相关测试,其结论是time=0时,正常访问的吞吐量下降为10%;当time=1000时,吞吐量和没有备份时的性能一致。 是否真是如此呢,我们来亲自测试一下。 下面是测试结果: 其中concurrency代表sysbench中 --num-threads的数值。 OPT代表该环境下,没有mysqldump时的sysbench QPS。 余下两列分别代表有mysqldump时的sysbench QPS。
由结果可以看出,time=1000并没有给查询性能带来很大的提升。最佳情况下也只是比time=0时提高80%的性能。 为什么呢? 其实不难理解,表中的concurrency很大程度上决定了测试page的冷热程度。并发数越大,每面产生的并行请求就越多,从而每个page被访问的频率就越高,page在LRU链表中的位置也就越靠顶端。反之亦然。 那么我们来想想下高频率热点数据访问时的情况。这时虽然mysqldump访问的page会不断加载在LRU顶端,但是高频度的热点数据访问会以更快的速度把page再次抢占到LRU顶端。从而导致mysqldump加载入的page会被迅速刷下,并立即被evict(淘汰)。因此,time=0或1000对这种压力环境下的访问不会造成很大影响,因为dump的数据根本抢占不过热点数据。 同样,超低频率的数据访问也是一样的情况。由于数据访问频度很低,大量的page都处于LRU链表的尾端。所以无论dump的page被加载到head或是midpoint位置,都会在热点数据的前面。也就是说无论怎样,数据page都会被淘汰。所以,这种压力环境下的性能同样不会随着time值的配置变化有很大浮动。 真正能够享受到time带来的福利的是那些 处于midpoint边缘的不温不火的数据。 从下图也可以看出,性能提升最大的情况集中在中等访问量的情况下,也即 37%的位置上 三、 Mid Point位置带来的影响从之前的分析也可以得出这样的结论:innodb_old_blocks_time 的作用范围对page的冷热情况有直接联系。而innodb_old_blocks_pct 又决定了BP的数据分布。 那么 innodb_old_blocks_pct 的调节,能够左右 innodb_old_blocks_time的影响范围。 上图的曲线也证明了这样的观点。当innodb_old_blocks_pct 调节到60%时,波峰也相应平移到了 60%的位置。 |
| 下一个产品 SQL计算timestamp的差值的方法 上一个产品 MySql官方手册学习笔记1 MySql简单上手 |