如何排查并解决 Amazon DocumentDB 实例上的 CPU 利用率过高问题？

2 分钟阅读

我观察到我的 Amazon DocumentDB（与 MongoDB 兼容）数据库实例的 CPU 利用率很高。

简短描述

Amazon DocumentDB 实例的 CPU 利用率可帮助您了解当前分配的资源在持续工作负载下的性能。

由于以下原因，您可能会发现 CPU 利用率有所增加：

用户启动的繁重工作负载
查询效率低下
集群中的写入器负担过重，因为集群中的读取负载不平衡
读取器的硬件配置低于写入器，无法与高写入工作负载同步
内部任务，例如 Amazon DocumentDB 集群中的垃圾回收
数据库连接过多（空闲）
短暂的连接突增

要确定 Amazon DocumentDB 实例中 CPU 利用率的主要来源，请查看以下方面：

Amazon CloudWatch 指标
性能见解
本机数据库查询
检查查询的效率
激进的日志记录设置

确定原因后，分析和优化您的工作负载以降低 CPU 利用率。如果问题仍然存在，请根据您的工作负载增加您的实例大小。

解决方法

使用 CloudWatch 指标

Amazon DocumentDB 与 CloudWatch 集成，允许您收集和分析集群的运行指标。

CloudWatch 指标允许您识别长时间内的 CPU 及其比例指标模式。查看这些指标，然后在 CloudWatch 控制台中对其进行监控：

使用 DatabaseConnections 和 DatabaseConnectionsMax 来识别在相关时间轴上打开的连接数量。
使用 WriteIOPs、ReadIOPs、ReadThroughput 和 WriteThroughput 来了解 Amazon DocumentDB 实例。
使用 DocumentsDeleted、DocumentsInserted、DocumentsReturned 和 DocumentsUpdated。这些指标可以帮助您了解您的 Amazon DocumentDB 实例上的用户工作负载。
如果您使用 T3 或 T4 实例类别，请查看 CPUCreditBalance 和 CPUSurplusCreditBalance 以检查计算限制。

使用性能详情指标

使用 Amazon DocumentDB 性能详情来识别导致数据库加载和等待状态的查询。在管理指标选项下，使用平均活跃会话数来查看负载和 CPU 分布（system%、user% 或 total%）。

平均负载大于 vCPU 数量表示该实例处于负载过重的状态。例如，平均负载可能小于数据库实例类的 vCPU。这表明 CPU 限制可能不是应用程序延迟的原因。检查平均负载并分析相关的等待状态，以了解增加 CPU 利用率的来源，例如 I/O、锁定和锁存。

使用本机数据库查询

本机查询可以帮助您分析工作负载并检查 CPU 利用率。使用 MongoDB Shell 运行此查询。这列出了当前在 Amazon DocumentDB 实例上运行的所有操作：

db.adminCommand({currentOp: 1, $all: });

此查询使用 currentOp 命令列出所有被阻止或运行时间超过 10 秒的查询：

db.adminCommand({aggregate: 1,
                 pipeline: [{$currentOp: {}},
                            {$match: {$or: [{secs_running: {$gt: 10}},
                                            {WaitState: {$exists: true}}]}},
                            {$project: {_id:0,
                                        opid: 1,
                                        secs_running: 1,
                                        WaitState: 1,
                                        blockedOn: 1,
                                        command: 1}}],
                 cursor: {}
                });

要分析系统使用结果，请在观察到 CPU 利用率较高的实例上运行此查询。此查询返回在每个命名空间中运行的所有查询的汇总。它还列出了所有内部系统任务以及每个命名空间的唯一等待状态数。

db.adminCommand({aggregate: 1,
                 pipeline: [{$currentOp: {allUsers: true, idleConnections: true}},
                            {$group: {_id: {desc: "$desc", ns: "$ns", WaitState: "$WaitState"}, count: {$sum: 1}}}],
                 cursor: {}
                });

**注意：**内部任务下的 GARBAGE_COLLECTION 指标是 Amazon DocumentDB 集群中的 MVCC 实施。这是一个后台浏览器，用于删除失效的文档版本，并与数据库上的更新或删除次数有关。扫描过程是根据集合级别的内部阈值触发的，并导致读/写 IOP 和 CPU 利用率。

检查查询的效率

检查写入查询的索引开销

与数据库关联的索引过多或大量未使用的索引可能会增加写入开销。查看索引统计数据以分析索引使用情况并进行识别。

查看查询的解释计划

查询运行速度可能很慢，因为它们需要对收集进行全面扫描才能选择相关文档。创建适当的索引以提高查询速度。

使用 explain 命令标识要在其上创建索引的字段。您还可以使用探查器日志来捕获长时间运行的查询及其操作的详细信息。

查看集合统计信息

查看您使用的集合的以下统计信息：

查看性能详情中的热门查询部分，找出对负载贡献最大的集合。
查看集合的统计信息，以了解对其执行的插入、更新和删除操作的数量。您还可以查看执行的索引扫描和完整集合扫描的数量。
拆分您的集合以减小要处理的文档大小，尤其是在您有大量更新操作的情况下。

检查激进的日志记录设置

事件审计的优先级高于数据库流量。如果不需要审计，则可以将其关闭。如果您确实需要审计，请将 audit_logs 参数设置为仅记录必要的事件。为增加负载做好计划，然后根据需要切换到更大的实例类。

对于探查器日志，请确保为 profiler_threshold_ms 参数设置正确的值，以避免进行激进的日志记录。检查您的应用程序工作负载，确定将查询归类为长时间运行所需的正确阈值。

确认您已为要导出到 CloudWatch 的日志激活了日志导出选项。

使用最佳实践

将读取工作负载转移到读取器

如果您的 Amazon DocumentDB 集群中有多个数据库实例，请将读取工作负载转移到您的读取器实例。作为副本集连接时，请为连接指定 readPreference。如果您将读取首选项指定为 secondaryPreferred，则客户端会尝试将读取查询路由到您的副本。客户端尝试将写入查询路由到您的主数据库实例。

请注意，读取器具有最终一致性。如果工作负载需要更强的先写后读一致性，则使用动态读取首选项并在查询级别将其覆盖。例如，您可能会在连接级别默认为 secondaryPreferred，这样查询就会进入辅助查询。如果您的查询需要更强的先写后读一致性，则可以覆盖默认值。看这个例子：

db.collection.find().readPref("primary")

向集群添加一个或多个读取器实例

如果您有一个带有单个数据库实例（仅限写入器）的 Amazon DocumentDB 集群，请向该集群添加一个或多个读取器数据库实例。然后使用 readPreference=secondaryPreferred 来有效地处理负载。

使用 Amazon DocumentDB Profiler 识别慢速查询

使用 Amazon DocumentDB Profiler 记录慢速查询。如果某个查询在慢速查询日志中反复出现，则可能需要额外的索引来提高性能。

查找具有一个或多个阶段且至少执行一个 COLLSCAN 阶段的长时间运行的查询。表示查询阶段必须读取集合中的每个文档才能提供对查询的响应。

有关更多信息，请参阅剖析 Amazon DocumentDB（与 MongoDB 兼容）中运行缓慢的查询。

使用 CloudWatch 创建警报通知

创建 CloudWatch 警报，在 CPU 利用率指标超过特定阈值时通知您。

纵向扩展数据库实例的实例类

如果没有进一步的查询调整范围，请纵向扩展集群中实例的实例类以处理工作负载。

**注意：**如果纵向扩展实例类，则会增加成本。有关更多信息，请参阅 Amazon DocumentDB 定价。