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 每秒执行的命令数(如 createIndexdropCollection);从节点会显示 “本地 复制”(如 `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)或优化数据访问模式(减少大文档的频繁读取)。

posted on 2025-10-16 09:03  阿陶学长  阅读(7)  评论(0)    收藏  举报