MySQL · 特性分析 · innodb buffer pool相关特性

背景

innodb buffer pool做为innodb最重要的缓存，其缓存命中率的高低会直接影响数据库的性能。因此在数据库发生变更，比如重启、主备切换实例迁移等等，innodb buffer poll 需要一段时间预热，期间数据库的性能会受到明显影响。
另外mysql 5.7以前innodb buffer pool缓存大小修改不是动态的，重启才能生效。因此innodb buffer pool的预热和innodb buffer pool大小的动态修改，对性能要求较高的应用来说是不错的特性，下面我来看看这两个特性的具体实现。

buffer pool 预热

MySQL 5.6以后支持buffer pool预热功能。引入了以下参数, 参数具体含义参见官方文档。

innodb_buffer_pool_load_now
innodb_buffer_pool_dump_now
innodb_buffer_pool_load_at_startup
innodb_buffer_pool_dump_at_startup
innodb_buffer_pool_filename

buffer pool预热分为dump过程和load过程，均由后台线程buf_dump_thread完成。
比如用户发起set命令

set global innodb_buffer_pool_dump_now=on;
set global innodb_buffer_pool_load_now=on;

set 命令会立刻返回，具体操作由buf_dump_thread来实现。

  • dump 过程

    锁buf_pool
    遍历LRU链表，将(space, pageno) 先收集到数组
    释放锁
    再将数据写入innodb_buffer_pool_filename定有的文件中

  • load过程

    从文件读入数组
    按（space,pageno)排序数据
    依次同步读取页到buffer pool中

dump过程一般比较快，而load过程相对要慢些。

通过Innodb_buffer_pool_dump_status、Innodb_buffer_pool_load_status可查看dump/load的状态

另外5.7引入了performance_schema.events_stages_current来显示load进度，每load 32M会更新一条进度信息

select * from performance_schema.events_stages_current;
THREAD_ID       19
EVENT_ID        1367
END_EVENT_ID    NULL
EVENT_NAME      stage/innodb/buffer pool load
SOURCE  buf0dump.cc:619
TIMER_START     33393877311000
TIMER_END       33398961258000
TIMER_WAIT      5083947000
WORK_COMPLETED  0
WORK_ESTIMATED  1440
NESTING_EVENT_ID        NULL
NESTING_EVENT_TYPE      NULL

WORK_ESTIMATED表示总page数
WORK_COMPLETED表示当前已load page数

dump文件的数据格式如下

#cat ib_buffer_pool |more
0,7
0,1
0,3
0,2
0,4
0,11
0,5
0,6

dump文件比较简单，我们可以编辑此文件来预加载指定page,比较灵活。

buffer pool 动态调整大小

5.7 开始支持buffer pool 动态调整大小，每个buffer_pool_instance都由同样个数的chunk组成(chunks数组), 每个chunk内存大小为innodb_buffer_pool_chunk_size(实际会偏大5%，用于存放chuck中的block信息)。buffer pool以innodb_buffer_pool_chunk_size为单位进行动态增大和缩小。调整前后innodb_buffer_pool_size应一直保持是innodb_buffer_pool_chunk_size*innodb_buffer_pool_instances的倍数。

同样的buffer pool动态调整大小由后台线程buf_resize_thread,set命令会立即返回。通过InnoDB_buffer_pool_resize_status可以查看调整的运行状态。

  • resize流程

    • 如果开启了AHI，需禁用AHI
    • 如果是收缩内存
      1. 计算需收缩的chunk数， 从chunks开始尾部删除指定个数的chunk.
      2. 锁buf_pool
      3. 从free_list中摘除待删chunk的page放入待删链表buf_pool->withdraw
      4. 如果待删chunk的page为脏页，则刷脏
      5. 重新加载LRU中要删除的页，从LRU中摘除，重新从free列表获取page老的page放入待删链表buf_pool->withdraw
      6. 释放buffer pool锁
      7. 如果需收缩的chunk pages没有收集全，重复2-6
    • 开始resize
      1. 锁住所有instance的buffer_pool，page_hash
      2. 收缩pool：以chunk为单位释放要收缩的内存
      3. 清空withdraw列表buf_pool->withdraw
      4. 增大pool:分配新的chunk
      5. 重新分配buf_pool->chunks
      6. 如果改变/缩小超过2倍，会重置page hash，改变桶大小
      7. 释放buffer_pool,page_hash锁
      8. 如果改变/缩小超过2倍,会重启和buffer pool大小相关的内存结构，如锁系统(lock_sys_resize)，AHI(btr_search_sys_resize), 数据字段(dict_resize)等
    • 如果禁用了AHI，此时开启

由上可以看出，扩大内存比缩小内存相对容易些。缩小内存时，如果遇到有事务一直未提交且占用了待收缩的page时，导致收缩一直重试，error log会打印这种重试信息，
包含可能引用此问题的事务信息。为了避免频繁重试，每次重试的时间间隔会指数增长。

以上步骤中resize阶段buffer pool会不可用，此阶段会锁所有buffer pool, 但此阶段都是内存操作，时间比较短。收缩内存阶段耗时可能会很长，也有一定影响，但是每次都是以instance为单位进行锁定的。
总的来说，buffer pool 动态调整大小对应用的影响并不大。

  • 重新加载LRU中要删除的页的影响

    search 过程中btr游标保存的page可能重新加载过，自适应哈希保存的root page也可能重新加载过, 都需要重新读取。

总结

buffer pool 预热 和buffer pool 动态调整大小，这两功能相辅相承的。buffer pool 动态调整大小只适用于实例在主机本地升级的情况，如果用户修改buffer pool大小，同时涉及跨机迁移，那么buffer pool 预热功能就排上用场了。
另外buffer pool 动态调整尽量在业务低锋时进行。

时间： 2024-10-28 08:49:57

MySQL · 特性分析 · innodb buffer pool相关特性的相关文章

innodb buffer pool相关特性

背景 innodb buffer pool作为innodb最重要的缓存,其缓存命中率的高低会直接影响数据库的性能.因此在数据库发生变更,比如重启.主备切换实例迁移等等,innodb buffer poll 需要一段时间预热,期间数据库的性能会受到明显影响. 另外mysql 5.7以前innodb buffer pool缓存大小修改不是动态的,重启才能生效.因此innodb buffer pool的预热和innodb buffer pool大小的动态修改,对性能要求较高的应用来说是不错的特性,下面

MySQL · 引擎特性 · InnoDB Buffer Pool

前言 用户对数据库的最基本要求就是能高效的读取和存储数据,但是读写数据都涉及到与低速的设备交互,为了弥补两者之间的速度差异,所有数据库都有缓存池,用来管理相应的数据页,提高数据库的效率,当然也因为引入了这一中间层,数据库对内存的管理变得相对比较复杂.本文主要分析MySQL Buffer Pool的相关技术以及实现原理,源码基于阿里云RDS MySQL 5.6分支,其中部分特性已经开源到AliSQL.Buffer Pool相关的源代码在buf目录下,主要包括LRU List,Flu List,Do

MySQL · 特性分析 · InnoDB transaction history

1. 背景 在写压力负载比较重的MySQL实例上, InnoDB可能积累了较长的没有被purge掉的transaction history,导致实例性能的衰减,或者空闲空间被耗尽,下面就来看看它是怎么产生的,或者有没有什么方法来减轻,避免这样的问题出现. 2. InnoDB purge概要 InnoDB是一个事务引擎,实现了MVCC特性,也就是在存储引擎里对行数据保存了多个版本.在对行数据进行delete或者update更改时,行数据的前映像会保留一段时间,直到可以被删除的时候. 在大部分OLT

MySQL内核月报 2015.02-MySQL · 性能优化· InnoDB buffer pool flush策略漫谈

背景 我们知道InnoDB使用buffer pool来缓存从磁盘读取到内存的数据页.buffer pool通常由数个内存块加上一组控制结构体对象组成.内存块的个数取决于buffer pool instance的个数,不过在5.7版本中开始默认以128M(可配置)的chunk单位分配内存块,这样做的目的是为了支持buffer pool的在线动态调整大小. Buffer pool的每个内存块通过mmap的方式分配内存,因此你会发现,在实例启动时虚存很高,而物理内存很低.这些大片的内存块又按照16KB

MySQL 5.7.5: Buffer Pool 转储、恢复 以及存在的问题

MySQL提供了一个比较有用的功能,能够把buffer pool LRU上的block对应的page id 和space id 存储到文件中.在重启时,会自动读取这个转储文件,然后把对应的<space id, page id>读入到buffer pool中,快速预热内存,以尽快提供服务. 参数 使用该特性比较简单,通过多个参数控制. 简单说下几个参数 转储到文件: innodb_buffer_pool_dump_now  : 立刻做一次buffer pool  LRU dump innodb_

MySQL 5.7 对buffer pool list scan的优化

worklog: http://dev.mysql.com/worklog/task/?id=7047 原作者Innam 跳槽到twitter后 将该特性合并到webscalesql: https://github.com/webscalesql/webscalesql-5.6/commit/c834781321d97b914c3712c663bd7209175a3fe2#diff-07468177c19cc3f32d25913fe731f936R1814 在该worklog中,主要对LRU L

[MySQL 源码] 从buffer pool中获取空闲block流程

当我们将一个page读入内存时,需要先为其分配一个block,从buffer pool中获取.入口函数为buf_LRU_get_free_block 之前在http://mysqllover.com/?p=303有简要介绍,这里详细看看,当然,跟最近博客的主题一样,我们还是主要针对压缩表来分析. 以下分析基于Percona Server 5.5.18 buf_LRU_get_free_block loop: 1.block = buf_LRU_get_free_only(buf_pool) 首先

MySQL · 特性分析 · innodb 锁分裂继承与迁移

innodb行锁简介 行锁类型 LOCK_S:共享锁 LOCK_X: 排他锁 GAP类型 LOCK_GAP:只锁间隙 LOCK_REC_NO_GAP:只锁记录 LOCK_ORDINARY: 锁记录和记录之前的间隙 LOCK_INSERT_INTENTION: 插入意向锁,用于insert时检查锁冲突 每个行锁由锁类型和GAP类型组成 例如: LOCK_X|LOCK_ORDINARY 表示对记录和记录之前的间隙加排他锁 LOCK_S|LOCK_GAP 表示只对记录前的间隙加共享锁 锁的兼容性: 值

MySQL · 源码分析 · InnoDB LRU List刷脏改进之路

之前的一篇内核月报MySQL · 引擎特性 · InnoDB Buffer Pool 中对InnoDB Buffer pool的整体进行了详细的介绍.文章已经提到了LRU List以及刷脏的工作原理.本篇文章着重从MySQL 5.7源码层面对LRU List刷脏的工作原理,以及Percona针对MySQL LRU Flush的一些性能问题所做的改进,进行一下分析. 在MySQL中,如果当前数据库需要操作的数据集比Buffer pool中的空闲页面大的话,当前Buffer pool中的数据页就必须