RDS for MySQL实际内存分配情况介绍

Love The Way You Lie 2022-05-31 10:58 177阅读 0赞

RDS 的内存是重要的性能参数，常常出现由于异常的 SQL 请求以及待优化的数据库导致内存利用率升高的情况，严重时还会出现由于 OOM 导致实例发生 HA 切换的情况。

MySQL 的内存大体可以分为共享内存和 session 私有内存两部分，下面将详细介绍各部分的构成。

共享内存  
执行如下命令，即可查询示例的共享内存分配情况：

show variables where variable_name in ( 'innodb_buffer_pool_size','innodb_log_buffer_size','innodb_additional_mem_pool_size','key_buffer_size','query_cache_size' );

如下是内存规格为 240 M 的 RDS 实例的共享内存分配情况的查询结果：

+---------------------------------+-----------------+
    | Variable_name | Value | +---------------------------------+-----------------+
    | innodb_additional_mem_pool_size | 2097152         |
    | innodb_buffer_pool_size | 67108864 | | innodb_log_buffer_size          | 1048576         |
    | key_buffer_size                 | 16777216        |
    | query_cache_size | 0 | +---------------------------------+-----------------+
    共返回 5 行记录,花费 342.74 ms.

参数说明：

innodb\_buffer\_pool

该部分缓存是 Innodb 引擎最重要的缓存区域，是通过内存来弥补物理数据文件的重要手段，在 RDS 上会采用实例规格配置的 80% 作为该部分大小（上图即是 240M \* 0.8 = 192 M）。其中主要包含数据页、索引页、undo 页、insert buffer、自适应哈希索引、锁信息以及数据字典等信息。在进行 SQL 读和写的操作时，首先并不是对物理数据文件操作，而是先对 buffer\_pool 进行操作，然后再通过 checkpoint 等机制写回数据文件。该空间的优点是可以提升数据库的性能、加快 SQL 运行速度，缺点是故障恢复速度较慢。

innodb\_log\_buffer

该部分主要存放 redo log 的信息，在 RDS 上会设置 1 M 的大小。InnoDB 会首先将 redo log 写在这里，然后按照一定频率将其刷新回重做日志文件中。该空间不需要太大，因为一般情况下该部分缓存会以较快频率刷新至 redo log（Master Thread 会每秒刷新、事务提交时会刷新、其空间少于 1/2 时同样会刷新）。

innodb\_additional\_mem\_pool

该部分主要存放 InnoDB 内的一些数据结构，在 RDS 中统一设置为 2 M。通常是在 buffer\_pool 中申请内存的时候还需要在额外内存中申请空间存储该对象的结构信息。该大小主要与表数量有关，表数量越大需要更大的空间。

key\_buffer

该部分是 MyISAM 表的重要缓存区域，所有实例统一为 16 M。该部分主要存放 MyISAM 表的键。MyISAM 表不同于 InnoDB 表，其缓存的索引缓存是放在 key\_buffer 中的，而数据缓存则存储于操作系统的内存中。RDS 的系统是 MyISAM 引擎的，因此在 RDS 中是给予该部分一定量的空间的。

query\_cache

该部分是对查询结果做缓存以减少解析 SQL 和执行 SQL 的花销，在 RDS 上关闭了该部分的缓存。主要适合于读多写少的应用场景，因为它是按照 SQL 语句的 hash 值进行缓存的，当表数据发生变化后即失效。

Session 私有内存  
共享内存中介绍的内存空间是实例创建时即分配的内存空间，并且是所有连接共享的。而出现 OOM 异常的实例都是由于下面各个连接私有的内存造成的。

执行如下命令，查询示例的 session 私有内存分配情况：

show variables where variable_name in ( 'read_buffer_size','read_rnd_buffer_size','sort_buffer_size','join_buffer_size','binlog_cache_size','tmp_table_size' );

查询结果如下（如下为测试实例配置）：

+-------------------------+-----------------+
    | Variable_name           | Value           |
    +-------------------------+-----------------+
    | binlog_cache_size | 262144          |
    | join_buffer_size | 262144          |
    | read_buffer_size | 262144          |
    | read_rnd_buffer_size | 262144          |
    | sort_buffer_size | 262144          |
    | tmp_table_size | 262144          |
    +-------------------------+-----------------+
    共返回 6 行记录,花费 356.54 ms.

参数说明：

read\_buffer&read\_rnd\_buffer

分别存放了对顺序和随机扫描（例如按照排序的顺序访问）的缓存，RDS 给每个 session 设置 256 K 的大小。当 thread 进行顺序或随机扫描数据时会首先扫描该 buffer 空间以避免更多的物理读。

sort\_buffer

需要执行 order by 和 group by 的 SQL 都会分配 sort\_buffer，用于存储排序的中间结果，在 RDS 上设置 256 K。在排序过程中，若存储量大于 sort\_buffer\_size，则会在磁盘生成临时表以完成操作。在 Linux 系统中，当分配空间大于 2 M 时会使用 mmap() 而不是 malloc() 来进行内存分配，导致效率降低。

join\_buffer

MySQL 仅支持 nest loop 的 join 算法，RDS 设置 256 K 的大小。处理逻辑是驱动表的一行和非驱动表联合查找，这时就可以将非驱动表放入 join\_buffer，不需要访问拥有并发保护机制的 buffer\_pool。

binlog\_cache

该区域用来缓存该 thread 的 binlog 日志，RDS 设置 256 K 的大小。在一个事务还没有 commit 之前会先将其日志存储于 binlog\_cache 中，等到事务 commit 后会将其 binlog 刷回磁盘上的 binlog 文件以持久化。

tmp\_table

不同于上面各个 session 层次的 buffer，这个参数可以在控制台上修改。该参数是指用户内存临时表的大小，如果该 thread 创建的临时表超过它设置的大小会把临时表转换为磁盘上的一张 MyISAM 临时表。如果用户在执行事务时遇到类似如下这样的错误，可以考虑增大 tmp\_table 的值。

[Err] 1114 - The table '/home/mysql/data3081/tmp/#sql_6197_2' is full

参考：  
[https://help.aliyun.com/knowledge\_detail/51799.html][https_help.aliyun.com_knowledge_detail_51799.html]  
[https://yq.aliyun.com/articles/211][https_yq.aliyun.com_articles_211]

[https_help.aliyun.com_knowledge_detail_51799.html]: https://help.aliyun.com/knowledge_detail/51799.html
[https_yq.aliyun.com_articles_211]: https://yq.aliyun.com/articles/211