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
- 如果是收缩内存
- 计算需收缩的chunk数, 从chunks开始尾部删除指定个数的chunk.
- 锁buf_pool
- 从free_list中摘除待删chunk的page放入待删链表buf_pool->withdraw
- 如果待删chunk的page为脏页,则刷脏
- 重新加载LRU中要删除的页,从LRU中摘除,重新从free列表获取page老的page放入待删链表buf_pool->withdraw
- 释放buffer pool锁
- 如果需收缩的chunk pages没有收集全,重复2-6
- 开始resize
- 锁住所有instance的buffer_pool,page_hash
- 收缩pool:以chunk为单位释放要收缩的内存
- 清空withdraw列表buf_pool->withdraw
- 增大pool:分配新的chunk
- 重新分配buf_pool->chunks
- 如果改变/缩小超过2倍,会重置page hash,改变桶大小
- 释放buffer_pool,page_hash锁
- 如果改变/缩小超过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也可能重新加载过, 都需要重新读取。
本文详细介绍了MySQL InnoDB存储引擎的Buffer Pool动态调整过程,包括内存增缩的步骤、线程处理和影响分析。在调整过程中,若开启AHI(Adaptive Hash Index)则需要临时禁用,并在调整后重新启用。缩小内存可能因事务阻塞导致长时间等待,而扩大内存相对较快。整个过程中,Buffer Pool会经历锁池、重新分配内存、刷新脏页等操作,尽量减少对应用的影响。
548

被折叠的 条评论
为什么被折叠?



