GreatSQL内存消耗异常排查攻略：从系统到应用层面的深入分析

发布时间：2025-11-04 19:03:31 来源：技术快报 作者：系统运维

当 GreatSQL 数据库处于高并发高负载时，内存可能会发现 mysqld 进程的消耗析内存消耗远远超出设置的 innodb_buffer_pool_size 时，有时候甚至会高达甚至超过系统内存的异常应用90%，遇到这种问题时，排查心里经常会发慌，攻略担心下一秒内存就会爆了发生 OOM，从系层面或者数据库hang死不响应。入分

本文和大家试着使用 GreatSQL 中的内存 sys schema 和 performance_schema 进行深入分析，找出内存消耗大户的消耗析源头，并尽可能解决问题。异常应用

下面是排查详细的排查方法和步骤。

1. 确认实际内存消耗

1.1 操作系统层面分析

先检查确认 mysqld 进程的攻略内存具体消耗占用情况，做到心里有数，从系层面避免真的入分下一秒就发生 OOM 的问题：

在上述结果中重点关注几个指标：

看到 mysqld 进程当前内存消耗占比约 90%，还算可控，没到火烧眉毛的境地。

继续使用 pmap 查看 mysqld 进程中的内存分布情况：

看到大量的匿名内存（anon）消耗较多内存，云服务器提供商这可能是由以下几个原因引起的：

GreatSQL 在运行过程中会频繁地进行内存分配和释放，这些内存通常是以匿名映射的形式存在于进程的虚拟地址空间中。

例如，GreatSQL 的线程池、缓存、临时表等都会动态分配内存。

GreatSQL 使用大量的缓冲区和缓存来提高性能，例如InnoDB Buffer Pool（以下简称 IBP）、InnoDB Log Buffer等。

这些缓冲区和缓存通常会占用大量的匿名内存。

线程堆栈：

每个线程都有自己的堆栈空间，这些堆栈空间也是匿名内存的一部分。

为了响应用户请求而创建了大量线程，那么这些线程的堆栈空间会占用不少内存。

临时文件：

GreatSQL 在处理大查询或排序操作时，可能会使用临时表、临时文件，其内存映射也会占用匿名内存。

内存泄漏：

如果 GreatSQL 存在内存泄漏问题，也会导致匿名内存不断增加。高防服务器

可以针对上述各个模块/维度做进一步排查分析。

1.2 检查 IBP 内存相关配置

从上面可见 IBP 设置为 20G，但是 mysqld 进程的内存占用为 27.7G，超过 IBP 较多，这可能是由于用户的 SQL 请求（比如效率较低的慢查询 SQL）其他模块或线程引起。还需要继续排查。

2. 利用 Performance Schema 排查内存消耗来源

从 5.6.6 版本开始，Performance Schema 默认启用，是一个内置的性能诊断工具，用于实时监控和分析 GreatSQL 服务器的运行状态。它提供了详细的性能数据，包括 内存分配的全局视图、SQL 语句的执行时间、线程活动、锁等待等详细信息，帮助开发者和 DBA 识别和解决性能瓶颈。

2.1 按内存模块查看占用

使用 memory_summary_global_by_event_name 按模块查看内存分配情况：

例如：

索引或表分区的状态：位图被用来记录索引或分区的使用状态。例如，在分区表扫描时，通过位图可以高效管理哪些分区需要扫描或已经扫描。

事务或锁状态：记录事务的特定标志位或锁的使用状态，比如资源锁（resource locks）的分配状态。

InnoDB 的内部操作：位图被用于跟踪一些内部存储引擎的优化过程，例如自适应哈希索引、页的脏位（dirty bit）标记等。

线程管理：管理线程池中线程的分配和使用状态。

性能统计：在某些性能分析的场景下，位图用于记录启用或禁用的统计模块。

临时文件数据：排序、分组、联接等操作过程中生成的中间结果。

二进制日志：binlog 的写入和读取操作中使用缓存。

文件块：GreatSQL 访问文件时，将数据块加载到缓存中，避免重复读取。

表数据：表扫描或索引扫描时，用于缓存表或索引的数据。

如果 memory/sql/temporary_table 值较高，说明内存被临时表消耗。

如果 memory/innodb/hash_index 值较高，可能是 InnoDB 的自适应哈希索引占用内存。

上面的查询结果表明，memory/innodb/buf_buf_pool(IBP) 占用内存约 20G，memory/group_rpl/GCS_XCom::xcom_cache(MGR XCom Cache) 占用内存约 1G，都是符合预期的。但是 memory/mysys/IO_CACHE 占用的内存较高，需要重点排查。

2.2 跟踪各模块内存使用变化

可以每间隔一段时间重复执行下面的 SQL 请求，观察各个模块的内存消耗变化，找出内存消耗增长较快的模块，它们可能就是导致 mysqld 进程消耗较大内存的“元凶”。

结合前面各模块当前占用的内存情况，从上述查询结果综合分析看，较大概率应该就是 memory/mysys/IO_CACHE 模块消耗内存过大。

2.3 按线程查看内存占用

接着继续查看各线程内存占用情况，确认是否有个别线程（尤其是长连接线程）消耗了过多内存资源。使用 memory_summary_by_thread_by_event_name 查看各线程的内存分配，同时关联查询 threads 视图，可以显示各线程当前正在执行的 SQL 请求及其执行耗时：

从上面的查询结果可见，当前有较多的 LOAD DATA 请求正在运行，有可能是它们导致的内存占用较高的原因。

其中

排查分析道这里，基本上可以推断是由于有大量并发 LOAD DATA 导入数据请求导致 mysqld 内存占用较高。

3. 利用 sys schema 简化分析

相对于用 Performance Schema 排查分析，采用 sys schema 分析则更简单省事。接下来介绍如何利用 sys schema 分析。

GreatSQL sys schema 是一组视图、存储过程和函数的集合，它基于 performance_schema 提供了更易读和易用的性能数据汇总。sys schema 通过简化复杂的性能指标，帮助数据库管理员和开发人员快速诊断和优化 GreatSQL 的性能问题。

3.1 查看全局及各模块内存分布

首先，查看当前全部内存分配情况：

在 IBP 设置为 20G 的前提下，从 memory_global_total 查询到的内存分配总数并没有超过太多，说明较大可能性是由于用户的 SQL 请求（比如效率较低的慢查询 SQL）或其他模块引起。

继续查询内存使用的全局分布情况：

在 sys schema 中，大部分视图都同时存储原始数据以及格式化后可读性更强的两种视图。所以上面的 SQL 查询还可以改成查询原始未格式化的视图：

从上面两个查询结果可知，除了 IBP 和 MGR 之外，模块 memory/mysys/IO_CACHE 占用的内存最高，是重点分析排查对象。

查看 sys.memory_global_by_current_bytes 视图定义，可知它的原始数据来自 performance_schema：

相关文章