mongostat 命令

mongostat 是 MongoDB 自带的轻量级监控工具，功能类似 Linux 的 vmstat，能按固定时间间隔（默认 1 秒）采集实例运行指标并输出，是运维人员排查性能瓶颈、监控实例健康状态的核心工具。本文将从连接方式、结果解读、高级参数到实战排查，全面讲解 mongostat 的使用方法。

一、基础用法：连接不同场景的 MongoDB 实例

mongostat 支持连接本地单机实例、复制集等场景，核心是通过命令行参数指定连接信息、输出次数和间隔。以下是两种典型场景的实战命令。

1.1 连接本地单机实例

适用于开发环境或单机部署的生产环境，需指定主机、端口、认证信息（若开启）。

 

# 命令格式：mongostat --host=主机 --port=端口 --username=用户名 --humanReadable=true --authenticationDatabase=认证库 -n 输出次数 采集间隔
mongostat --host=127.0.0.1 --port=27017 --username=admin --humanReadable=true --authenticationDatabase=admin -n 20 1

 

 

关键参数解释：

 

• --humanReadable=true：将内存、流量等指标转换为易读单位（如 G、k），避免原始数字难以理解。
• -n 20：指定输出 20 次后停止（若不指定，会持续输出直到手动按 Ctrl+C 终止）。
• 1：采集间隔为 1 秒（单位：秒），可根据需求调整（如 5 秒采集一次则写 5）。
• --authenticationDatabase=admin：指定认证数据库（通常为 admin，与创建用户时的数据库一致）。

1.2 连接 MongoDB 复制集

生产环境多采用复制集部署，需指定所有节点地址（避免单点依赖），格式与单机类似。

 

# 连接复制集：指定多个节点地址，用逗号分隔
mongostat --host=20.20.20.64:27017,20.20.20.65:27017,20.20.20.66:27017 --username=admin --humanReadable=true --authenticationDatabase=admin -n 20 1

 

 

执行后会自动识别复制集角色（主节点 PRIMARY、从节点 SECONDARY），并在输出结果中体现（repl 字段）。

二、核心解读：mongostat 输出结果含义

执行命令后，会输出多列指标，每一行代表一个采集周期的数据。以下结合实际输出示例，按 “功能分类” 解读关键字段，重点标注需警惕的阈值。

2.1 输出示例（节选）

 

insert  query update delete getmore command dirty  used flushes vsize   res qrw arw net_in net_out conn            set           repl                time*0     4     *0     *0       0    35|0  0.1% 79.6%       0 11.3G 8.86G 0|0 0|0  10.2k    373k  103 myabc_mongo_rs   SLV Apr 10 10:27:26.560*0     0     *0     *0       3    10|0  0.1% 79.6%       0 11.3G 8.86G 0|0 0|0   6.37k   66.3k  103 myabc_mongo_rs   SLV Apr 10 10:27:28.559

 

2.2 字段分类解读

按功能可将字段分为 4 类，其中 标红部分为需重点监控的指标。

（1）读写操作类：反映业务访问压力

字段	含义
insert	每秒插入的文档数，带 * 表示该操作是复制集同步的操作（从节点特有）。
query	每秒执行的查询操作数（含普通查询、聚合查询等）。
update	每秒执行的更新操作数。
delete	每秒执行的删除操作数。
getmore	每秒通过游标获取批量数据的操作数（如分页查询的后续请求）。
command	每秒执行的命令数（如 createIndex、dropCollection）；从节点会显示 “本地	复制”（如 `35	0`），前者是本地命令，后者是复制命令。

（2）缓存与存储类：反映实例资源占用（重点关注）

这类指标直接关联性能瓶颈，尤其是 WiredTiger 引擎（MongoDB 3.2+ 默认引擎）下的 dirty 和 used。

 

字段	含义与阈值警示
dirty	WiredTiger 引擎的脏数据比例（内存中未刷到磁盘的数据）。   ⚠️ 阈值：5%（触发主动刷盘）、20%（阻塞新请求，全力刷盘）。
used	WiredTiger 引擎已占用的内存比例（MongoDB 默认最大占用系统内存的 60%）。   ⚠️ 阈值：80%（触发 LRU 淘汰旧数据）、95%（阻塞操作，全力淘汰数据）。
flushes	刷盘次数：WiredTiger 下是检查点（checkpoint）次数，MMAPv1 下是 fsync 次数。   ⚠️ 频繁刷盘（如每秒 1 次以上）可能导致 IO 压力过大。
vsize	MongoDB 占用的虚拟内存大小（单位：G），通常大于物理内存，无需过度关注。
res	MongoDB 占用的物理内存大小（单位：G），需结合系统内存判断是否溢出。

（3）连接与网络类：反映请求拥堵情况

字段	含义与阈值警示
qrw	客户端等待处理的读写队列长度（格式：读队列	写队列，如 `0	0`）。   ⚠️ 队列长度持续大于 5，说明实例处理速度跟不上请求量，可能有慢查询或资源瓶颈。
arw	客户端正在处理的活跃读写操作数（格式：读	写）。   ⚠️ 数值持续过大（如超过 50），需检查是否有耗时操作阻塞线程。
net_in	实例每秒接收的网络流量（含 mongostat 自身流量），单位通常为 k（千字节）。
net_out	实例每秒发送的网络流量，单位通常为 k 或 M（如大查询会导致该值骤增）。
conn	当前打开的连接总数（含应用连接、mongostat 连接等），需小于 MongoDB 最大连接数（默认 65536）。

（4）复制集信息类：反映集群角色与时间

字段	含义
set	复制集名称（如示例中的 myabc_mongo_rs），确认连接的集群是否正确。
repl	节点角色：PRI（主节点）、SLV（从节点）、ARB（仲裁节点）。
time	采集该条数据的时间戳，用于定位问题发生时间。

三、高级用法：自定义输出字段

默认输出的字段较多，若只需关注特定指标（如仅监控查询量和内存占用），可通过 -o 和 -O 参数自定义输出，减少信息干扰。

3.1 -o：仅输出指定字段

-o 会屏蔽默认字段，只显示你指定的列，适合聚焦单一维度监控。格式为 字段1,字段2=别名（可选），支持对指标做 rate()（每秒比率）或 diff()（两次采集差值）计算。

 

# 示例：仅输出主机、插入率、查询率、命令率、缓存请求数
mongostat --host=127.0.0.1 --port=27017 --username=admin --humanReadable=true --authenticationDatabase=admin -n 5 1 -o='host,opcounters.insert.rate()=Insert Rate,opcounters.query.rate()=Query Rate,opcounters.command.rate()=Command Rate,wiredTiger.cache.pages requested from the cache=Pages Req'

 

 

输出结果（简洁聚焦）：

 

           host Insert Rate Query Rate Command Rate   Pages Req
127.0.0.1:27017           0          0            3 10809493343
127.0.0.1:27017           0          3           36 10809494060

 

3.2 -O：在默认字段基础上增加自定义字段

-O 不会屏蔽默认输出，而是在默认列后追加指定字段，适合需要保留基础指标、同时补充额外信息的场景（如查看 MongoDB 版本）。

 

# 示例：默认字段 + 主机 + 版本 + 网络请求数
mongostat --host=127.0.0.1 --port=27017 --username=admin --humanReadable=true --authenticationDatabase=admin -n 3 1 -O='host,version,network.numRequests=network requests'

 

 

输出结果（默认列 + 新增列）：

 

insert query update delete getmore command dirty  used flushes vsize   res qrw arw net_in net_out conn            set           repl                time            host version network requests*0     0     *0     *0       0     2|0  0.0% 79.5%       0 11.3G 8.90G 0|0 0|0   560b   59.5k  103 myabc_mongo_rs   SLV Apr 10 11:13:25.792 127.0.0.1:27017  5.0.13        140029101

 

四、实战排查：常见问题与解决方案

通过 mongostat 发现异常后，需结合指标定位问题根源。以下是 3 类高频问题的排查思路。

4.1 问题 1：qrw 队列持续大于 5（请求拥堵）

• 现象：qrw 字段如 3|5（读队列 3，写队列 5），且持续 10 秒以上。
• 排查步骤：
  1. 查看 query/update 字段，确认是否有突发的请求量增长（如业务峰值）。
  2. 若请求量正常，需排查慢查询（通过 mongosh 执行 db.currentOp() 查看当前耗时操作）。
• 解决方案：
  • 若为业务峰值，可临时扩容实例或优化请求频率（如缓存热点数据）。
  • 若为慢查询，需添加索引（如 db.collection.createIndex({field:1})）或优化查询语句（避免全表扫描）。

4.2 问题 2：dirty 比例超过 10%（脏数据堆积）

• 现象：dirty 字段如 15%，且持续上升（接近 20% 阈值）。
• 原因：写入速度超过刷盘速度，导致内存中未刷盘的数据堆积。
• 解决方案：
  1. 检查 flushes 字段，确认是否刷盘频率过低（如 5 分钟以上未刷盘）。
  2. 临时调整 WiredTiger 刷盘参数（需谨慎，建议先咨询官方）：db.adminCommand({setParameter: 1, wiredTigerEngineRuntimeConfig: "checkpoint=(wait=60)"})（设置每 60 秒强制刷盘一次）。
  3. 长期解决方案：升级磁盘 IO 性能（如从 HDD 换 SSD）或拆分写入压力（如分库分表）。

4.3 问题 3：used 比例超过 85%（内存占用过高）

• 现象：used 字段如 88%，且持续上升（接近 95% 阈值）。
• 原因：缓存的热数据过多，或存在内存泄漏（罕见）。
• 解决方案：
  1. 查看 res 字段，确认物理内存是否真的不足（如 res=11G，系统内存仅 16G）。
  2. 执行 db.runCommand({clearCache: 1}) 手动清理缓存（仅临时缓解，需谨慎在业务低峰执行）。
  3. 长期解决方案：增加实例内存（如从 16G 升级到 32G）或优化数据访问模式（减少大文档的频繁读取）。