MySQL · 特性分析 · innodb_buffer_pool_size在线修改

本文涉及的产品
RDS SQL Server Serverless,2-4RCU 50GB 3个月
推荐场景:
RDS PostgreSQL Serverless,0.5-4RCU 50GB 3个月
推荐场景:
对影评进行热评分析
云数据库 RDS SQL Server,基础系列 2核4GB
简介: InnoDB Buffer Pool缓存了表数据和二级索引在内存中,提高数据库效率,因此设置innodb_buffer_pool_size到合理数值对实例性能影响很大。当size设置偏小,会导致数据库大量直接磁盘的访问,而设置过大会导致实例占用内存太多,容易发生OOM。

InnoDB Buffer Pool缓存了表数据和二级索引在内存中,提高数据库效率,因此设置innodb_buffer_pool_size到合理数值对实例性能影响很大。当size设置偏小,会导致数据库大量直接磁盘的访问,而设置过大会导致实例占用内存太多,容易发生OOM。在MySQL 5.7之前innodb_buffer_pool_size的修改需要重启实例,在5.7后支持了动态修改innodb_buffer_pool_size。本文会根据源码介绍该特性。

innodb_buffer_pool_size 设置范围

innodb_buffer_pool_size默认值是128M,最小5M(当小于该值时会设置成5M),最大为LLONG_MAX。当innodb_buffer_pool_instances设置大于1的时候,buffer pool size最小为1GB。同时buffer pool size需要是innodb_buffer_pool_chunk_size*innodb_buffer_pool_instances的倍数。innodb_buffer_pool_chunk_size默认为128M,最小为1M,实例启动后为只读参数。

static MYSQL_SYSVAR_LONGLONG(buffer_pool_size, innobase_buffer_pool_size,
  PLUGIN_VAR_RQCMDARG,
  "The size of the memory buffer InnoDB uses to cache data and indexes of its tables.",
  innodb_buffer_pool_size_validate,
  innodb_buffer_pool_size_update,
  static_cast<longlong>(srv_buf_pool_def_size),//128M
  static_cast<longlong>(srv_buf_pool_min_size),//5M
  LLONG_MAX, 1024*1024L);

#define BUF_POOL_SIZE_THRESHOLD   (1024 * 1024 * 1024) //1GB

static
int
innodb_buffer_pool_size_validate(
{
  ...
  //当srv_buf_pool_instances > 1,要求size不小于1GB。
  if (srv_buf_pool_instances > 1 && intbuf < BUF_POOL_SIZE_THRESHOLD) {
    buf_pool_mutex_exit_all();

    push_warning_printf(thd, Sql_condition::SL_WARNING,
          ER_WRONG_ARGUMENTS,
          "Cannot update innodb_buffer_pool_size"
          " to less than 1GB if"
          " innodb_buffer_pool_instances > 1.");
    return(1);
  }
  ...
  ulint requested_buf_pool_size
  = buf_pool_size_align(static_cast<ulint>(intbuf));
}



/** Calculate aligned buffer pool size based on srv_buf_pool_chunk_unit,
if needed.
@param[in]  size  size in bytes
@return aligned size */
UNIV_INLINE
ulint
buf_pool_size_align(
  ulint size)
{
  const ulint m = srv_buf_pool_instances * srv_buf_pool_chunk_unit;
  size = ut_max(size, srv_buf_pool_min_size);

  if (size % m == 0) {
    return(size);
  } else {
    return((size / m + 1) * m);
  }
}

buffer pool resize流程

  • 如果开启了AHI(adaptive hash index,自适应哈希索引)就关闭AHI,这里因为AHI是通过buffer pool中的B+树页构造而来。

  • 如果新设定的buffer pool size小于原来的size,就需要计算需要删除的chunk数目withdraw_target。

  • 遍历buffer pool instances,锁住buffer pool,收集free list中的chunk page到withdraw,直到withdraw_target或者遍历完,然后释放buffer pool锁。

  • 停止加载buffer pool。

  • 如果free list中没有收集到足够的chunk,则重复遍历收集,每次重复间隔时间会指数增加1s、2s、4s、8s…,以等待事务释放资源。

  • 锁住buffer pool,开始增减chunk。

  • 如果改变比较大,超过2倍,会重置page hash,改变桶大小。

  • 释放buffer_pool,page_hash锁。

  • 改变比较大时候,重新设置buffer pool大小相关的内存结构。

  • 开启AHI。

/** Resize the buffer pool based on srv_buf_pool_size from
srv_buf_pool_old_size. */
void
buf_pool_resize()
{
  /* disable AHI if needed */
  btr_search_disable(true);

  /* set withdraw target */
  for (ulint i = 0; i < srv_buf_pool_instances; i++) {
    if (buf_pool->curr_size < buf_pool->old_size) {
      ...
      while (chunk < echunk) {
        withdraw_target += chunk->size;
        ++chunk;
      }
      ...
    }
  }

  /* wait for the number of blocks fit to the new size (if needed)*/
  for (ulint i = 0; i < srv_buf_pool_instances; i++) {
    buf_pool = buf_pool_from_array(i);
      if (buf_pool->curr_size < buf_pool->old_size) {

      should_retry_withdraw |=
       buf_pool_withdraw_blocks(buf_pool);
    }
  }
  ...
  if (should_retry_withdraw) {
  ib::info() << "Will retry to withdraw " << retry_interval
    << " seconds later.";
  os_thread_sleep(retry_interval * 1000000);

  if (retry_interval > 5) {
    retry_interval = 10;
  } else {
    retry_interval *= 2;
    }

    goto withdraw_retry;
  }
  ...
  /* add/delete chunks */
  for (ulint i = 0; i < srv_buf_pool_instances; ++i) {
    if (buf_pool->n_chunks_new < buf_pool->n_chunks) {
      /* delete chunks */
      /* discard withdraw list */
    }
  }
  /* reallocate buf_pool->chunks */
  if (buf_pool->n_chunks_new > buf_pool->n_chunks) {
    /* add chunks */
  }
  ...
  const bool  new_size_too_diff
  = srv_buf_pool_base_size > srv_buf_pool_size * 2
    || srv_buf_pool_base_size * 2 < srv_buf_pool_size;

  /* Normalize page_hash and zip_hash,
  if the new size is too different */
}

resize过程中的等待和阻塞

在支持动态修改innodb_buffer_pool_size之前,该值的修改需要修改配置项然后重启实例生效。而重启实例会导致用户连接强制断开,导致一段时间的实例不可用,如果有大事务在回滚就需要等待很长时间。

动态修改innodb_buffer_pool_size只有在收集回收块;查找持有block阻止buffer pool收集回收chunk的事务;resizing buffer pool操作时会阻塞用户写入。而这几部分操作都是内存操作,会较快完成。

如果对innodb_buffer_pool_size修改量很大,同时遇到page cleaner工作时间久,就可能导致一段时间的阻塞。例如下面一个较为极端的例子,innodb_buffer_pool_instances为1,innodb_buffer_pool_size由18GB改为5M,innodb_buffer_pool_chunk_size为1M,page cleaner loop花费近48s,导致收集回收块会花费很长时间,可以看到在测试机器上用时近48s。而这期间的写入操作也会被阻塞。

02:54:09.798912Z 0 [Note] InnoDB: Withdrawing blocks to be shrunken.
02:54:09.798935Z 0 [Note] InnoDB: buffer pool 0 : start to withdraw the last 1151680 blocks.
02:54:57.660725Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 47685ms. The settings might not be optimal. (flushed=0 and evicted=0, during the time.)
02:54:57.687189Z 0 [Note] InnoDB: buffer pool 0 : withdrawing blocks. (1151680/1151680)
02:54:57.687237Z 0 [Note] InnoDB: buffer pool 0 : withdrew 1151653 blocks from free list. Tried to relocate 27 pages (1151680/1151680).
02:54:57.753014Z 0 [Note] InnoDB: buffer pool 0 : withdrawn target 1151680 blocks.


> insert into t values(10000001, 2);
Query OK, 1 row affected (9.03 sec)

正常不需要等待时的内存操作会很快。

03:31:57.734231Z 0 [Note] InnoDB: Resizing buffer pool from 1887436800 to 5242880 (unit=1048576).
03:31:58.480061Z 0 [Note] InnoDB: Completed to resize buffer pool from 1887436800 to 5242880.
...
03:31:46.453250Z 10 [Note] InnoDB: Resizing buffer pool from 524288 (new size: 1887436800 bytes)
03:31:57.734231Z 0 [Note] InnoDB: Resizing buffer pool from 1887436800 to 5242880 (unit=1048576).

另一个方面,如果当前有事务占用大量buffer pool数据导致无法收集到足够的chunk,resize过程也会变久。下面极端测试中当执行xa rollback回滚大事务的时候,innodb_buffer_pool_chunk_size由16M改为5M,即等待了较久时间才完成回收chunk的收集。不过这段时间并不会完全阻塞用户的操作。

> xa begin 'y';
Query OK, 0 rows affected (0.00 sec)

> update t set c2 = 2 where c2 =1;
Query OK, 999996 rows affected (8.32 sec)
Rows matched: 999996  Changed: 999996  Warnings: 0

> xa end 'y';
Query OK, 0 rows affected (0.00 sec)

> xa prepare 'y';
Query OK, 0 rows affected (0.11 sec)

> xa rollback 'y';
Query OK, 0 rows affected (10.10 sec)

InnoDB: Resizing buffer pool from 16777216 to 5242880 (unit=1048576).
InnoDB: Withdrawing blocks to be shrunken.
InnoDB: buffer pool 0 : start to withdraw the last 704 blocks.
InnoDB: buffer pool 0 : withdrew 239 blocks from free list. Tried to relocate 126 pages (689/704).
InnoDB: buffer pool 0 : withdrew 0 blocks from free list. Tried to relocate 0 pages (689/704).
...
InnoDB: Will retry to withdraw 1 seconds later.
InnoDB: buffer pool 0 : start to withdraw the last 704 blocks.
...
InnoDB: buffer pool 0 : will retry to withdraw later.
InnoDB: Will retry to withdraw 2 seconds later.
...
InnoDB: buffer pool 0 : will retry to withdraw later.
InnoDB: Will retry to withdraw 4 seconds later.
InnoDB: buffer pool 0 : start to withdraw the last 704 blocks.
...
InnoDB: Will retry to withdraw 8 seconds later.
InnoDB: buffer pool 0 : withdrawn target 704 blocks.

从上面可以看到innodb_buffer_pool_size的online修改相比重启对用户实例的影响降低了很多,但也最好选择业务低峰期和没有大事务操作时候进行,同时要修改MySQL配置文件,防止重启后恢复到原来的值。

相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
6天前
|
存储 SQL 关系型数据库
MySQL底层概述—2.InnoDB磁盘结构
InnoDB磁盘结构主要包括表空间(Tablespaces)、数据字典(Data Dictionary)、双写缓冲区(Double Write Buffer)、重做日志(redo log)和撤销日志(undo log)。其中,表空间分为系统、独立、通用、Undo及临时表空间,分别用于存储不同类型的数据。数据字典从MySQL 8.0起不再依赖.frm文件,转而使用InnoDB引擎存储,支持事务原子性DDL操作。
165 100
MySQL底层概述—2.InnoDB磁盘结构
|
6天前
|
缓存 算法 关系型数据库
MySQL底层概述—1.InnoDB内存结构
本文介绍了InnoDB引擎的关键组件和机制,包括引擎架构、Buffer Pool、Page管理机制、Change Buffer、Log Buffer及Adaptive Hash Index。
155 97
MySQL底层概述—1.InnoDB内存结构
|
3天前
|
SQL 关系型数据库 MySQL
MySQL底层概述—10.InnoDB锁机制
本文介绍了:锁概述、锁分类、全局锁实战、表级锁(偏读)实战、行级锁升级表级锁实战、间隙锁实战、临键锁实战、幻读演示和解决、行级锁(偏写)优化建议、乐观锁实战、行锁原理分析、死锁与解决方案
MySQL底层概述—10.InnoDB锁机制
|
6天前
|
存储 缓存 关系型数据库
MySQL底层概述—5.InnoDB参数优化
本文介绍了MySQL数据库中与内存、日志和IO线程相关的参数优化,旨在提升数据库性能。主要内容包括: 1. 内存相关参数优化:缓冲池内存大小配置、配置多个Buffer Pool实例、Chunk大小配置、InnoDB缓存性能评估、Page管理相关参数、Change Buffer相关参数优化。 2. 日志相关参数优化:日志缓冲区配置、日志文件参数优化。 3. IO线程相关参数优化: 查询缓存参数、脏页刷盘参数、LRU链表参数、脏页刷盘相关参数。
MySQL底层概述—5.InnoDB参数优化
|
6天前
|
存储 SQL 关系型数据库
MySQL底层概述—4.InnoDB数据文件
本文介绍了InnoDB表空间文件结构及其组成部分,包括表空间、段、区、页和行。表空间是最高逻辑层,包含多个段;段由若干个区组成,每个区包含64个连续的页,页用于存储多条行记录。文章还详细解析了Page结构,分为通用部分(文件头与文件尾)、数据记录部分和页目录部分。此外,文中探讨了行记录格式,包括四种行格式(Redundant、Compact、Dynamic和Compressed),重点介绍了Compact行记录格式及其溢出机制。最后,文章解释了不同行格式的特点及应用场景,帮助理解InnoDB存储引擎的工作原理。
MySQL底层概述—4.InnoDB数据文件
|
6天前
|
存储 缓存 关系型数据库
MySQL底层概述—3.InnoDB线程模型
InnoDB存储引擎采用多线程模型,包含多个后台线程以处理不同任务。主要线程包括:IO Thread负责读写数据页和日志;Purge Thread回收已提交事务的undo日志;Page Cleaner Thread刷新脏页并清理redo日志;Master Thread调度其他线程,定时刷新脏页、回收undo日志、写入redo日志和合并写缓冲。各线程协同工作,确保数据一致性和高效性能。
MySQL底层概述—3.InnoDB线程模型
|
11天前
|
存储 SQL 缓存
MySQL原理简介—2.InnoDB架构原理和执行流程
本文介绍了MySQL中更新语句的执行流程及其背后的机制,主要包括: 1. **更新语句的执行流程**:从SQL解析到执行器调用InnoDB存储引擎接口。 2. **Buffer Pool缓冲池**:缓存磁盘数据,减少磁盘I/O。 3. **Undo日志**:记录更新前的数据,支持事务回滚。 4. **Redo日志**:确保事务持久性,防止宕机导致的数据丢失。 5. **Binlog日志**:记录逻辑操作,用于数据恢复和主从复制。 6. **事务提交机制**:包括redo日志和binlog日志的刷盘策略,确保数据一致性。 7. **后台IO线程**:将内存中的脏数据异步刷入磁盘。
|
1月前
|
SQL 关系型数据库 MySQL
MySQL事务日志-Undo Log工作原理分析
事务的持久性是交由Redo Log来保证,原子性则是交由Undo Log来保证。如果事务中的SQL执行到一半出现错误,需要把前面已经执行过的SQL撤销以达到原子性的目的,这个过程也叫做"回滚",所以Undo Log也叫回滚日志。
MySQL事务日志-Undo Log工作原理分析
|
28天前
|
关系型数据库 MySQL 数据库
mysql慢查询每日汇报与分析
通过启用慢查询日志、提取和分析慢查询日志,可以有效识别和优化数据库中的性能瓶颈。结合适当的自动化工具和优化措施,可以显著提高MySQL数据库的性能和稳定性。希望本文的详解和示例能够为数据库管理人员提供有价值的参考,帮助实现高效的数据库管理。
40 11
|
2月前
|
存储 缓存 关系型数据库
【MySQL进阶篇】存储引擎(MySQL体系结构、InnoDB、MyISAM、Memory区别及特点、存储引擎的选择方案)
MySQL的存储引擎是其核心组件之一,负责数据的存储、索引和检索。不同的存储引擎具有不同的功能和特性,可以根据业务需求 选择合适的引擎。本文详细介绍了MySQL体系结构、InnoDB、MyISAM、Memory区别及特点、存储引擎的选择方案。
【MySQL进阶篇】存储引擎(MySQL体系结构、InnoDB、MyISAM、Memory区别及特点、存储引擎的选择方案)

相关产品

  • 云数据库 RDS MySQL 版
  • 推荐镜像

    更多