返回

RDS实例内存占用过高？排查与优化全攻略

mysql

RDS 实例内存占用过高排查与优化

服务器内存不够用了，咋整？这问题时不时就跳出来烦人。最近我就碰上了，RDS 数据库实例 (db.t3.micro) 内存占用率飙到 90%，关键是，啥也没跑！ 可用内存一直徘徊在 100MB 左右。 这不明摆着有问题吗？ 下面说说我是怎么一步步排查和解决的。

一、 问题现象及初步尝试

首先，现象很明确：db.t3.micro 实例，没跑业务的情况下，内存占用率 90% 左右，可用内存 (Freeable Memory) 只有 100MB 左右。

按照常规思路，我做了以下尝试（通过自定义参数组）：

  1. 重启 RDS 实例。
  2. Innodb_buffer_pool_size 从 268435456 降到 52428800。
  3. Max_connections 从 {DBInstanceClassMemory/12582880} 调整为 20。
  4. Tmp_table_size 从 134217728 降到 1048576。
  5. max_heap_table_size 从 134217728 降到 1048576。
  6. Table_open_cache 设置为 10 （之前为空）。
  7. Log_bin_trust_function_creators 设置为 0 （之前为空）。
  8. Log_bin_use_v1_row_events 设置为 0 （之前为空）。
  9. Event_scheduler 设置为 OFF（之前为空）

结果，没用！ 可用内存还是少得可怜。 问题来了，到底是什么东西占用了这么多内存？ 我得想办法找到“元凶”。

二、 内存占用分析方法

想知道谁吃了内存，就得有工具。下面几种方法可以帮我们找到占用内存的进程：

2.1 使用 Performance Insights (性能详情)

Performance Insights 是 RDS 提供的一个功能强大的性能监控工具，可以很方便的查看数据库负载，不过它是收费的！如果只是看看OS的参数，可以用Enhanced monitoring。

原理: Performance Insights 通过收集和分析数据库引擎的性能数据，帮助用户识别性能瓶颈。它可以展示各种指标，包括操作系统级别的指标，例如内存使用情况。

操作步骤：

  1. 打开 RDS 控制台，找到对应的数据库实例。
  2. 进入 "监控" 选项卡。
  3. 找到 "Enhanced monitoring"，查看 OS 进程列表，通常按内存消耗排序，可以看到消耗资源最多的进程. 如果之前没开Enhanced monitoring,现在开也行。
  4. 找到 Performance Insights，按需调整时间范围。 查看“操作系统进程”部分。 这里会列出消耗资源最多的进程,通常还会给出资源消耗曲线.

安全建议：

  • Performance Insights 可能会收集敏感信息，确保只有授权用户才能访问。
  • 长期使用注意查看费用。

2.2 使用 top 命令 (Linux)

top 命令是 Linux 系统中最常用的性能分析工具之一。如果可以 SSH 到 RDS 实例所在的服务器（通常情况下不能直接 SSH 到 RDS 实例，但是思路是相同的, 可以用来排查你自己的 Linux 服务器），可以用它来实时查看进程的内存占用情况。

原理： top 命令会动态显示系统中各个进程的资源占用状况，包括 CPU、内存、I/O 等。

命令行指令：

top

进入 top 界面后，可以按 Shift + M 按照内存使用率排序。 RES 列表示进程占用的物理内存大小。

注意： 我们一般无法通过 SSH 连接到 RDS 实例，这里只是为了理解如何去解决内存占用问题，如果是在EC2 上自己搭的数据库, 是可以用 top 的。

2.3 使用 ps 命令 (Linux)

ps 命令可以列出当前系统中的进程信息，可以结合其他命令（例如 sort、awk）来筛选和排序进程，找出占用内存最多的进程。

原理： ps 命令用于报告当前系统的进程状态。 我们可以使用不同的选项来获取不同的信息。

命令行指令：

ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%mem | head

这个命令会显示：

  • pid: 进程 ID
  • ppid: 父进程 ID
  • cmd: 启动进程的命令
  • %mem: 进程使用的物理内存百分比
  • %cpu: 进程使用的 CPU 百分比
  • --sort=-%mem: 按内存使用率降序排列
  • head 取前几条

同样，在 RDS 实例上无法直接执行，但这个命令的思路是清晰的。

2.4 show processlist (MySQL/MariaDB)

如在MySQL/MariaDB 中可以使用 show processlist

原理： show processlist 可以显示正在运行线程的信息.

命令行指令：

SHOW PROCESSLIST;

2.5 使用CloudWatch (增强监控)

CloudWatch的增强监控部分，可以看到系统内存占用。 虽不能直接提供具体哪个进程占用多少，可以看曲线，了解大概的消耗走势。

操作步骤：

  1. 进入 RDS 实例的监控页面.
  2. 切换到"增强监控"标签。
  3. 选择“操作系统进程列表”视图.
  4. 选择按"内存使用量%" 排序. 可以看消耗最大的.

三、 针对具体情况的优化建议

在知道了内存占用高的具体原因之后，就可以采取针对性的优化措施了。 针对文章开头提出的问题，结合前面几个查找方法, 结合 t3.micro 这个机型的特点, 可能的原因及优化方向如下:

3.1 确认是否有未提交的事务

长时间未提交的事务可能导致大量内存占用。

排查方法：

使用 SHOW ENGINE INNODB STATUS; 查看 TRANSACTIONS 部分，关注长时间未提交的事务。

优化建议：

  • 及时提交或回滚事务。
  • 如果发现有长时间未提交的事务，分析原因，并尽快处理。

3.2 检查慢查询

慢查询可能导致连接堆积，占用大量内存。

排查方法：

  • 开启慢查询日志（通过参数组设置 slow_query_log 为 1，并设置 long_query_time）。
  • 分析慢查询日志，找出执行时间过长的 SQL 语句。

优化建议：

  • 优化 SQL 语句，例如添加索引、改写 SQL。
  • 如果是业务逻辑问题，考虑优化业务逻辑。

3.3 适当调整连接数

过多的连接会占用大量内存。

优化建议：

  • 根据实际业务需求，适当降低 max_connections 的值（虽然前面已经尝试过了，但在找到真正原因之前，仍需考虑）。
  • 使用连接池来管理数据库连接，避免频繁创建和销毁连接。

3.4 检查是否有大结果集查询

查询返回大量数据，可能会占用大量内存。

排查方法：

  • 审查应用程序代码，是否有一次性查询大量数据的操作。
  • 分析慢查询日志, 发现返回很多 rows 的.

优化建议：

  • 尽量避免一次性查询大量数据，可以分页查询。
  • 如果必须返回大量数据，考虑使用流式读取方式。

3.5 升级实例规格(最终手段)

如果上述优化措施都无法解决问题，那么可能需要升级 RDS 实例规格（比如升级到 db.t3.small 或更高规格），增加内存容量。

操作步骤：
直接在 RDS 的控制面板操作。 调整配置即可.

操作风险及注意事项:

  • 费用上升。
  • 实例规格升级时可能会有短暂的不可用, 注意选低峰时间进行。

3.6 调整 innodb_buffer_pool_size（需谨慎）

对于 InnoDB 存储引擎，innodb_buffer_pool_size 参数控制着缓冲池的大小，它直接影响着数据库的性能。db.t3.micro 内存本身就小,需要精细控制.

原理： InnoDB 缓冲池用于缓存表数据和索引数据，减少磁盘 I/O 操作。

建议：
虽然之前尝试过调小,但还是要综合所有信息来定. 需要根据实际的业务负载和内存使用情况来调整这个参数，不是越小越好，也不是越大越好. 通常建议是总内存的50%-75%之间,但对 t3.micro，也许 20-30% 就足够了, 需要监控调整.

如何调整：
逐步尝试. 小范围改动。

3.7 关闭 Performance Schema （如果开启了的话）

MySQL 的 Performance Schema 也会占用一些内存，对于小规格实例，可以考虑关闭。

操作：

修改参数组,设置 performance_schema 为 0。

注意事项:
关闭后将无法使用部分性能诊断功能. 确认业务不依赖它.

四,总结和梳理

这次内存占用问题，其实暴露的是对数据库监控和资源管理的不足。排查这类问题, 就是一个抽丝剥茧的过程。要根据监控数据，结合各种命令，分析日志,一点点找出症结。以后需要做的是:

  1. 加强监控: 配置好 CloudWatch 报警，关键指标异常时及时通知。
  2. 定期审查: 定期检查慢查询、大事务等潜在问题。
  3. 压力测试: 新功能上线前，进行充分的压力测试，评估资源占用情况。
  4. 代码审查: 关注是否有一次性加载大量数据的SQL.

记住，优化是个持续的过程, 一次优化不能解决所有问题. 随着业务增长和变化，还需要不断地调整和优化.