MySQL OOM问题诊断与pt-mysql-summary工具实战

1. MySQL OOM问题诊断概述

最近在排查一个线上MySQL实例频繁重启的问题时，发现罪魁祸首是OOM（Out Of Memory）错误。这类问题在数据库运维中相当常见，特别是在内存配置不当或查询负载突增的情况下。经过多次实战，我总结出一套使用pt-mysql-summary工具进行系统化诊断的方法。

MySQL内存管理是个复杂的系统工程，涉及缓冲池、连接线程、排序缓存等多个组件。当这些内存区域的总和超过系统可用内存时，内核的OOM Killer就会介入，强制终止MySQL进程。这种突发性的服务中断对业务影响极大，因此需要一套完整的诊断方案。

2. 工具准备与环境检查

2.1 pt-mysql-summary安装配置

Percona Toolkit中的pt-mysql-summary是专门用于收集MySQL状态信息的利器。安装很简单：

# Ubuntu/Debian sudo apt-get install percona-toolkit # RHEL/CentOS sudo yum install percona-toolkit

安装后建议检查版本兼容性：

pt-mysql-summary --version

注意：生产环境建议使用与MySQL版本匹配的Toolkit版本，避免兼容性问题

2.2 基础环境检查

在开始诊断前，需要确认几个关键点：

1. 系统剩余内存：free -h
2. MySQL错误日志位置：show variables like 'log_error'
3. 当前内存配置：重点关注以下参数：

   SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; SHOW VARIABLES LIKE 'key_buffer_size'; SHOW VARIABLES LIKE 'tmp_table_size'; SHOW VARIABLES LIKE 'max_connections';

3. 完整诊断流程

3.1 信息收集阶段

执行完整信息收集（建议在问题发生时立即执行）：

pt-mysql-summary --user=root --password=xxx --host=127.0.0.1 --port=3306 > mysql_summary_$(date +%Y%m%d).log

关键收集项包括：

• 系统内存使用情况
• MySQL内存分配明细
• 活跃连接数及状态
• 正在执行的查询
• 临时表使用情况

3.2 内存配置分析

通过报告中的[Memory]部分，重点关注：

1. 缓冲池使用率：理想应在80%以下
2. 每个连接的内存消耗：计算公式为：

   连接内存 = read_buffer_size + read_rnd_buffer_size + sort_buffer_size + thread_stack + join_buffer_size

3. 临时内存使用：特别是created_tmp_disk_tables与created_tmp_tables的比值

3.3 问题查询定位

在报告中的[Processlist]部分，查找：

• 运行时间过长的查询
• 使用临时表的操作
• 大量排序操作
• 全表扫描语句

典型危险模式示例：

-- 大表全表扫描 SELECT * FROM user_logs WHERE create_time > '2020-01-01'; -- 未优化的JOIN SELECT a.*, b.* FROM big_table a JOIN huge_table b ON a.id = b.ref_id WHERE a.status = 1;

4. 解决方案与优化建议

4.1 紧急处理措施

当出现OOM征兆时：

1. 立即终止问题查询：

   KILL [query_id];

2. 临时降低并发数：

   SET GLOBAL max_connections = 100;

3. 增加swap空间（临时方案）：

   sudo fallocate -l 2G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile

4.2 长期优化方案

1. 内存分配策略优化：

   # my.cnf调整示例 innodb_buffer_pool_size = 12G # 物理内存的50-70% key_buffer_size = 256M tmp_table_size = 64M max_heap_table_size = 64M

2. 查询优化方案：

   • 为常用条件添加索引
   • 拆分大查询为分批处理
   • 避免SELECT * 写法
   • 优化JOIN操作

3. 监控体系建设：

   # 定期收集内存指标 pt-mysql-summary --user=monitor --password=xxx --host=127.0.0.1 --port=3306 > $(date +%Y%m%d)_mysql_summary.log

5. 实战案例解析

最近处理的一个典型案例：某电商平台大促期间MySQL频繁OOM。通过pt-mysql-summary发现：

1. 问题现象：

   • max_connections=500，但实际并发只有50左右
   • 每个连接平均消耗50MB内存
   • 存在多个10GB级别的临时表

2. 根本原因：

   • 报表查询未使用索引
   • join_buffer_size默认值过大(256MB)
   • 没有限制单个查询的内存使用

3. 解决方案：

   • 优化查询添加复合索引
   • 调整配置：

     join_buffer_size = 8M tmp_table_size = 32M max_execution_time = 30000

   • 增加查询审核流程

6. 高级技巧与注意事项

6.1 内存泄漏检测

对于疑似内存泄漏的情况：

1. 定期执行并对比报告：

   pt-mysql-summary --user=root --password=xxx > mem_report_$(date +%s).log

2. 重点关注：
   • 缓冲池使用增长趋势
   • 连接内存累计值
   • 未释放的临时表

6.2 容器化环境特殊处理

在K8s环境中额外注意：

1. Cgroup限制检查：

   cat /sys/fs/cgroup/memory/memory.limit_in_bytes

2. 建议配置：

   resources: limits: memory: "16Gi" requests: memory: "12Gi"

6.3 常见误区和陷阱

1. 缓冲池不是越大越好 - 需为OS和其他进程保留足够内存
2. 连接池配置不当会导致"连接风暴"
3. 排序操作可能消耗意想不到的内存
4. 子查询产生的临时表容易被忽视

重要提示：任何内存参数修改后，必须通过pt-mysql-summary验证实际效果，避免配置冲突