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 引擎的脏数据比例(内存中未刷到磁盘的数据)。
|
used |
WiredTiger 引擎已占用的内存比例(MongoDB 默认最大占用系统内存的 60%)。
|
flushes |
刷盘次数:WiredTiger 下是检查点(checkpoint)次数,MMAPv1 下是 fsync 次数。
|
vsize |
MongoDB 占用的虚拟内存大小(单位:G),通常大于物理内存,无需过度关注。 |
res |
MongoDB 占用的物理内存大小(单位:G),需结合系统内存判断是否溢出。 |
(3)连接与网络类:反映请求拥堵情况
字段 | 含义与阈值警示 | ||
---|---|---|---|
qrw |
客户端等待处理的读写队列长度(格式:读队列 | 写队列,如 `0 | 0`)。
|
arw |
客户端正在处理的活跃读写操作数(格式:读 | 写)。
|
|
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)或优化数据访问模式(减少大文档的频繁读取)。
- 查看