数据
聚焦技术和人文，分享干货，共同成长。
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 秒以上。
排查步骤：
查看 query/update 字段，确认是否有突发的请求量增长（如业务峰值）。
若请求量正常，需排查慢查询（通过 mongosh 执行 db.currentOp() 查看当前耗时操作）。
解决方案：
若为业务峰值，可临时扩容实例或优化请求频率（如缓存热点数据）。
若为慢查询，需添加索引（如 db.collection.createIndex({field:1})）或优化查询语句（避免全表扫描）。
4.2 问题 2：dirty 比例超过 10%（脏数据堆积）
现象：dirty 字段如 15%，且持续上升（接近 20% 阈值）。
原因：写入速度超过刷盘速度，导致内存中未刷盘的数据堆积。
解决方案：
检查 flushes 字段，确认是否刷盘频率过低（如 5 分钟以上未刷盘）。
临时调整 WiredTiger 刷盘参数（需谨慎，建议先咨询官方）：db.adminCommand({setParameter: 1, wiredTigerEngineRuntimeConfig: "checkpoint=(wait=60)"})（设置每 60 秒强制刷盘一次）。
长期解决方案：升级磁盘 IO 性能（如从 HDD 换 SSD）或拆分写入压力（如分库分表）。
4.3 问题 3：used 比例超过 85%（内存占用过高）
现象：used 字段如 88%，且持续上升（接近 95% 阈值）。
原因：缓存的热数据过多，或存在内存泄漏（罕见）。
解决方案：
查看 res 字段，确认物理内存是否真的不足（如 res=11G，系统内存仅 16G）。
执行 db.runCommand({clearCache: 1}) 手动清理缓存（仅临时缓解，需谨慎在业务低峰执行）。
长期解决方案：增加实例内存（如从 16G 升级到 32G）或优化数据访问模式（减少大文档的频繁读取）。
posted on
2025-11-06 06:52
阿陶学长
阅读(26)
评论(0)
收藏
举报
刷新页面返回顶部