监控MongoDB性能：关键命令与指标详解

有效的数据库管理依赖于稳健的监控。对于领先的NoSQL文档数据库MongoDB而言，理解性能指标对于维持高可用性和响应能力至关重要。慢查询、资源消耗过高或意外的连接激增都可能严重影响应用性能。

当MongoDB变慢时，第一个有用的问题不是“数据库坏了吗？”，而是“服务器现在在做什么，这与正常情况有何不同？”以下命令是我在更改索引、调整硬件或归咎于应用之前，进行初步排查时使用的命令。

MongoDB Shell (mongosh) 中的基本监控命令

运行这些命令的主要接口是MongoDB Shell (mongosh)，或旧版的mongo shell。此处显示的所有命令均在此Shell环境中执行。

1. 了解当前连接：db.currentOp() 和 db.serverStatus()

监控活跃连接对于防止连接耗尽以及识别可能阻塞资源的长时间运行操作至关重要。

db.currentOp()

此命令返回当前在数据库上执行的操作信息。对于实时识别慢查询或阻塞查询不可或缺。

使用示例：

查看所有当前正在运行的操作：

db.currentOp()

专门查找运行时间超过特定阈值的操作（例如，运行超过5秒的操作）：

db.currentOp({"secs_running": {$gt: 5}})

输出包含op（操作类型）、ns（命名空间）、query（查询）和secs_running（运行秒数）等详细信息。

db.serverStatus()

虽然此命令提供全面的状态信息，但其connections部分对于监控连接池和限制至关重要。

serverStatus中的关键指标（连接部分）：

• current：当前到服务器的活跃连接数。
• available：可以建立的可用连接数（基于配置的最大值）。

db.serverStatus().connections

2. 分析查询性能：db.getProfilingStatus() 和 db.setProfilingLevel()

MongoDB提供了内置的分析工具，用于记录数据库操作的执行细节，从而可以识别资源密集型查询。

分析级别

分析级别决定了记录哪些操作：

• 0（关闭）： 不分析任何操作。
• 1（慢操作）： 仅分析慢于配置阈值（slowms）的操作。
• 2（所有操作）： 分析所有操作，这会产生显著的写入负载，应仅在目标故障排除时短暂使用。

检查状态

查看当前分析级别：

db.getProfilingStatus()

设置级别（示例）

启用仅针对慢操作的分析（超过100毫秒的操作）：

// 将slowms设置为100毫秒（默认通常为100）
db.setProfilingLevel(1, { slowms: 100 })

提示： 收集到必要信息后，务必将分析级别恢复为0，以防止因过度日志记录而导致性能下降。

查看已分析的慢查询

分析过的操作存储在正在监控的特定数据库的system.profile集合中。要查看过去一小时内最慢的10个查询：

db.system.profile.find().sort({millis: -1}).limit(10).pretty()

3. 资源利用率指标

了解MongoDB如何利用CPU、内存和I/O资源对于扩展决策至关重要。

内存和存储使用情况：db.serverStatus()

serverStatus中的globalLock和storageEngine部分提供了对资源管理的深入洞察。

内存指标：

• resident：进程正在使用的物理内存量。
• virtual：进程分配的虚拟内存总量。

db.serverStatus().globalLock

锁争用监控

MongoDB使用内部锁定机制。监控锁的获取和等待有助于识别并发瓶颈。

globalLock中的关键指标：

• currentQueue.readers：等待锁的读取者数量。
• currentQueue.writers：等待锁的写入者数量。
• totalTime：所有操作等待锁的总时间。

currentQueue中的高值通常表明索引缺失或写入操作过长，导致读取者/写入者排队。

4. 索引使用和健康：db.collection.stats()

索引利用不佳或缺失是性能下降的最常见原因。stats()命令有助于分析索引效率。

在特定集合（例如users）上运行时：

db.users.stats()

要检查的关键指标：

• totalIndexSize：该集合上所有索引占用的总磁盘空间。
• indexSizes：每个索引的空间使用明细。
• 如果索引存在但从未用于读取，则它是应考虑移除的开销。

5. 磁盘I/O和吞吐量：db.serverStatus()（网络和操作）

监控网络活动和操作速率可以了解数据库吞吐量。

操作速率（来自opcounters）：

opcounters跟踪自上次服务器重启以来执行的操作总数，按类型分类：

• insert（插入）、query（查询）、update（更新）、delete（删除）、getmore（获取更多）、command（命令）。

通过跟踪这些计数器随时间的变化（例如，比较两次连续的serverStatus调用），可以计算操作吞吐量（每秒操作数）。

示例比较：

1. 在时间T1运行db.serverStatus().opcounters。
2. 在时间T2运行db.serverStatus().opcounters。
3. 从T2值中减去T1值，得到该时间间隔内执行的总操作数。

主动监控的最佳实践

• 自动化是关键： 仅依赖手动Shell命令效率低下。使用MongoDB Cloud Manager/Ops Manager或自动查询这些端点的第三方监控解决方案来集成监控。
• 建立基线： 在系统健康时运行命令以建立性能基线。任何偏离此基线的情况都值得立即调查。
• 关注延迟： 虽然操作计数很有用，但在诊断最终用户体验问题时，应优先考虑延迟指标（如分析日志报告的时间），而不是原始吞吐量。
• 频繁检查连接： 在高流量应用中，连接限制通常首先被触及。监控db.serverStatus().connections.current相对于配置的最大值。

实用的初步排查清单

当有人说“MongoDB很慢”时，避免直接跳到索引更改。从一个简短的清单开始，并记录你看到的内容。

检查服务器是否因活跃操作而过载：

db.currentOp({
  active: true,
  secs_running: { $gt: 2 }
});

少数长时间运行的操作对于分析任务可能是正常的。但大量写入、集合扫描或阻塞操作则不同。查看ns中的命名空间、op中的操作类型以及查询形状。如果许多操作都在等待一个更新或索引构建，那么修复方法不同于读取查询缺少索引的情况。

然后检查连接：

db.serverStatus().connections;

current快速上升可能意味着应用连接池配置错误、部署创建了太多工作线程，或者客户端超时并重新连接。available接近零是一个紧急信号，因为新客户端可能无法连接。正确的答案可能是在应用中调整连接池，而不是提高服务器限制。

接下来，在短时间内间隔检查两次操作计数器：

const a = db.serverStatus().opcounters;
sleep(5000);
const b = db.serverStatus().opcounters;
printjson({
  insertPer5s: b.insert - a.insert,
  queryPer5s: b.query - a.query,
  updatePer5s: b.update - a.update,
  deletePer5s: b.delete - a.delete,
  commandPer5s: b.command - a.command
});

自启动以来的计数器对于长期上下文很有用，但已知时间间隔内的差异可以告诉你当前正在发生什么。如果命令流量很高但查询很低，你可能看到的是元数据检查、监控噪音或驱动程序行为，而不是正常的读取。

在归咎于硬件之前使用explain()

分析集合可以告诉你哪些操作很慢。explain()可以帮助你在添加CPU或内存之前理解查询为何缓慢。

db.users.find({ email: "[email protected]" }).explain("executionStats");

在输出中，比较totalDocsExamined与nReturned。如果MongoDB检查了大量文档才返回一个用户，则该查询可能需要更好的索引或不同的过滤器。如果totalKeysExamined很高，则索引存在，但可能对于查询模式来说选择性不够。

对于复合查询，索引顺序很重要：

db.orders.find({
  accountId: "acct_123",
  status: "open",
  createdAt: { $gte: ISODate("2025-11-01T00:00:00Z") }
}).sort({ createdAt: -1 });

一个有用的索引可能是：

db.orders.createIndex({ accountId: 1, status: 1, createdAt: -1 });

这不是通用规则。最佳索引取决于基数、排序顺序以及访问该集合的所有查询。关键是让数据库向你展示执行计划，而不是猜测。

解读分析数据而不反应过度

分析级别2会记录每个操作，并可能在繁忙系统上增加开销。仅在短时间的目标窗口内使用它。级别1配合合理的slowms阈值对于查找慢操作更安全。

db.setProfilingLevel(1, { slowms: 200 });

收集数据后，检查最慢的条目：

db.system.profile.find(
  {},
  {
    ns: 1,
    op: 1,
    millis: 1,
    command: 1,
    keysExamined: 1,
    docsExamined: 1,
    nreturned: 1
  }
).sort({ millis: -1 }).limit(20).pretty();

一个慢查询并不总是意味着生产事故。计划报告、重启后的冷缓存或罕见的维护任务都可能出现在顶部。模式比单个样本更重要。如果相同的查询形状反复出现，并且检查的文档远多于返回的文档，那么你就有了一个真正的调优候选。

监控副本集和存储压力

对于副本集，性能不仅仅关乎主节点。落后的从节点会影响故障转移信心，以及如果客户端使用从节点读取时的读取工作负载。

rs.status();

查找不健康的成员、意外的状态更改或无法恢复的复制延迟。可接受的确切延迟取决于应用。类似队列的工作负载可能容忍一点延迟。承诺近实时读取的仪表板则可能不行。

存储压力也需要同样的上下文。db.serverStatus()可以显示存储引擎和WiredTiger指标，但磁盘级工具仍然重要。如果MongoDB正在等待慢速磁盘，数据库内部的Shell命令将显示症状而不是根本原因。与主机指标（如磁盘延迟、文件系统使用率、CPU窃取和内存压力）相关联。

将手动检查转化为告警

手动命令最适合在调查期间使用。对于正常操作，将有用的信号转化为自动化检查：连接使用率、复制健康、慢查询率、磁盘使用率、页面错误或缓存压力（如果可用）以及操作延迟。对持续的糟糕行为发出告警，而不是对每一分钟的峰值。

好的告警包含上下文。“MongoDB慢查询高”不如包含数据库、集合、查询形状、当前速率以及最近分析样本或仪表板面板链接的告警有用。目标是缩短事件发生后的前十分钟。

在缓慢期间不要做什么

避免同时进行多项更改。在同一事件中添加索引、增加连接限制、重启应用以及更改连接池大小可能会消除症状，但会让你不知道哪个操作起了作用。进行一次更改，观察应该改善的指标，并做好记录。

谨慎使用killOp。当一个操作明显有害时，它可能有用，但杀死随机长时间运行的操作可能会使应用行为更糟。如果该操作属于迁移、备份、索引构建或报告任务，在停止它之前先确定所有者，除非数据库已经处于严重困境。

不要将serverStatus()视为单一的神奇健康评分。它是计数器和快照的集合。高值在大型繁忙系统上可能是正常的，而低值在小型延迟敏感系统上可能是糟糕的。有用的问题是，该值是否以与用户面临问题相匹配的方式发生了变化。

还要将数据库症状与部署症状分开。改变查询形状、打开更大连接池或启动后台迁移的新版本发布可能使MongoDB看起来像是根本原因。在做出仅针对数据库的修复之前，将慢操作的时间与部署、作业计划、备份和流量变化进行比较。

当将当前行为与已知基线进行比较时，MongoDB监控效果最佳。db.currentOp()、db.serverStatus()、分析、explain()和副本集检查为你提供了足够的证据，以决定问题是查询、索引、客户端连接行为、复制还是数据库底层的主机。