前言:

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

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

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.

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

说到这里就不得不提一下BP的midpoint insert 机制。

下文就将对于这个机制做一定分析和讨论。

一、 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。

由于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。

Concurrency OPT old_time=0 old_time=1000
1 17394 1836 2141
2 29703 3670 3981
3 47347 5683 6540
4 64717 6805 8337
5 83551 8676 15885
6 99396 12978 19893
7 112330 16491 26022
8 126600 23840 33346
9 138468 30760 39194
10 150365 39034 48925
11 163053 43174 60352
12 174916 52066 70180
13 174160 63853 78076
14 173786 65164 80661
15 174268 70965 90633
16 175044 80871 102629
17 175583 90689 103423
18 175939 94805 112629
19 175114 93303 120625

由结果可以看出,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%的位置。

 总结:

1. innodb_old_blocks_time =1000 一定程度上可以降低mysqldump类型的访问对数据库性能带来的影响。

2. innodb_old_blocks_time =1000 的优化效果有限,对于处于midpoint附近的page能带来最大的提升效果。

 

mysqldump造成Buffer Pool污染的研究的更多相关文章

  1. [转]MySQL innodb buffer pool

    最近在对公司的 MySQL 服务器做性能优化, 一直对 innodb 的内存使用方式不是很清楚, 乘这机会做点总结. 在配置 MySQL 的时候, 一般都会需要设置 innodb_buffer_poo ...

  2. innodb buffer pool小解

    INNODB维护了一个缓存数据和索引信息到内存的存储区叫做buffer pool,他会将最近访问的数据缓存到缓冲区.通过配置各个buffer pool的参数,我们可以显著提高MySQL的性能. INN ...

  3. 14.6.3.1 The InnoDB Buffer Pool

    14.6.3.1 The InnoDB Buffer Pool InnoDB 保持一个存储区域被称为buffer pool 用于cache数据和索引在内存里, 知道InnoDB buffer pool ...

  4. 14.4.3.1 The InnoDB Buffer Pool

    14.4.3.1 The InnoDB Buffer Pool 14.4.3.2 Configuring Multiple Buffer Pool Instances 14.4.3.3 Making ...

  5. MySQL · 引擎特性 · InnoDB Buffer Pool

    前言 用户对数据库的最基本要求就是能高效的读取和存储数据,但是读写数据都涉及到与低速的设备交互,为了弥补两者之间的速度差异,所有数据库都有缓存池,用来管理相应的数据页,提高数据库的效率,当然也因为引入 ...

  6. 【MySQL】InnoDB 内存管理机制 --- Buffer Pool

    InnoDB Buffer Pool 是一块连续的内存,用来存储访问过的数据页面 innodb_buffer_pool_size 参数用来定义 innodb 的 buffer pool 的大小 是 M ...

  7. 020:Buffer Pool 、压缩页、CheckPoint、Double Write、Change Buffer

    一. 缓冲池(Buffer Pool) 1.1 缓冲池介绍 每次读写数据都是通过 Buffer Pool : 当Buffer Pool 中没有用户所需要的数据时,才去硬盘中获取: 通过 innodb_ ...

  8. MySql 缓冲池(buffer pool) 和 写缓存(change buffer) 转

    应用系统分层架构,为了加速数据访问,会把最常访问的数据,放在缓存(cache)里,避免每次都去访问数据库. 操作系统,会有缓冲池(buffer pool)机制,避免每次访问磁盘,以加速数据的访问. M ...

  9. 【大白话系统】MySQL 学习总结 之 缓冲池(Buffer Pool) 的设计原理和管理机制

    一.缓冲池(Buffer Pool)的地位 在<MySQL 学习总结 之 InnoDB 存储引擎的架构设计>中,我们就讲到,缓冲池是 InnoDB 存储引擎中最重要的组件.因为为了提高 M ...

随机推荐

  1. beta-1阶段各组员的贡献分分配

    小组名称:nice! 小组成员:李权 于淼 刘芳芳 韩媛媛 宫丽君 项目内容:约跑app 分数分配规则 个人贡献分=基本贡献分*0.2+特殊贡献分*0.3+个人代码贡献量*0.5 其中 基本贡献分,特 ...

  2. Linux命令之rz - 批量上传文件,简单易用(转载)

    用途说明 rz命令能够批量上传文件,当然也可上传单个文件啦.使用的协议是古老的ZMODEM协议,尽管协议古老,但毫不影响的简单易用的特性.一般情 况我们要上传文件到Linux系统,要么使用ftp(还得 ...

  3. linux 下yum使用技巧

    本文来自我的github pages博客http://galengao.github.io/ 即www.gaohuirong.cn 经常会遇上一些linux系统允许你上外网,而一些是不允许的,这时我们 ...

  4. 解决 ionic 中的 CORS(跨域)

    译者注:本人翻译功力有限,所以文中难免有翻译不准确的地方,凑合看吧,牛逼的话你看英文版的去,完事儿欢迎回来指正交流(^_^) 如果你通过 ionic serve 或者 ionic run 命令使用或 ...

  5. 2019-03-25-day018-面向对象

    re模块 字符串匹配 列表 = findall(正则表达式,待匹配的字符串) 找所有 结果集 = search 找第一个,结果集.group() 结果集 = match 从第一个字符开始匹配,结果集. ...

  6. 廖雪峰Java1-2程序基础-1基本结构

    1.类名 类名首字母大写 类名必须是英文字母.数字和下划线的组合 类名必须是以英文字母开头 好的命名:Hello NoteBook VRPlayer 不好的命名:hello 跟无意义的数字Good12 ...

  7. Java_单例模式

    主要介绍单例模式的一种写法.注意事项.作用.测试,以Java语言为例,下面代码是目前见过最好的写法: ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 ...

  8. Redhat7 Mesos安装

    $ sudo yum install -y tar wget git 1. 手工安装mavenwget http://mirrors.cnnic.cn/apache/maven/maven-3/3.3 ...

  9. 散度(Divergence)和旋度(Curl)

    原文链接 散度(Divergence) 散度的讨论应从向量和向量场说起.向量是数学中研究多维计算的基本概念.比如,速度可以分解为相互独立的分量,则速度就是一个多维的向量.假如空间中的每一个位置都有一个 ...

  10. Educational Codeforces Round 1 (C) (atan2 + long double | 大数)

    这题只能呵呵了. 东搞西搞,折腾快一天,最后用了一个800多行的代码AC了. 好好的题目你卡这种精度干啥. 还有要卡您就多卡点行不,为什么long double 又可以过... 废了N长时间写个了不管 ...