mongostat 无法监控 GridFS 文件级 QPS，因其仅统计底层文档操作（如 insert/find），而一个文件操作会拆解为数十至数百次 chunk 文档操作，query/insert 数值与实际文件上传下载次数无固定映射关系。
mongostat 不能监控 GridFS 的读写 QPS（每秒文件操作数），它显示的 query、insert、delete 是底层文档级操作频次，不是文件级 QPS。你看到的 “1000 query/s” 可能对应 2–3 个大文件下载，也可能对应 500 次小 chunk 查询——完全无法映射到业务语义。
mongostat 显示的 insert/query 数值和 GridFS 文件操作不对应
- GridFS 上传一个 50MB 文件，会触发约 200 次
insert（写入fs.chunks） + 1 次insert（写入fs.files），mongostat的insert列只反映这 201 次文档插入，不表示“1 次文件上传” - 下载同理：1 次
find（查fs.files） + 约 200 次find（查fs.chunks） → 全部计入query列，无法区分是元数据查询还是数据块拉取 -
getmore列在高并发下载时可能飙升，但这只是游标分批返回的副作用，不代表文件请求数增长 - 如果应用使用流式上传（
openUploadStream()），还可能触发大量update（更新fs.files.length或uploadDate），进一步污染 QPS 解读
为什么直接看 mongostat 的 query/insert 会误判负载
-
query高 ≠ 文件下载多：可能是客户端反复重试失败的find({filename: "x"})，也可能是后台定时任务扫描fs.files清理过期文件 -
insert和del同时高：大概率是旧版本文件被覆盖后，旧fs.chunks被批量delete，这不是正常上传流量，而是 GC 压力 -
netIn远高于netOut但query很低：说明大量数据正从客户端流入（上传主导），但mongostat无法告诉你这些字节是否最终落到了fs.chunks - 在分片集群中，
mongostat连接mongos时，query统计包含路由开销；连mongod时又只看到本 shard 的 chunk 操作，全局文件 QPS 无法拼合
怎么用 mongostat 获取一点可用线索（仅限排查异常）
- 启动时加
-o time,query,insert,del,netIn,netOut，导出 CSV 后用awk抽取关键列，观察趋势是否同步突增（例如insert和netIn同步翻倍，才较可能对应真实上传高峰） - 关注
qr（读队列）是否持续 > 0：若fs.chunks查询堆积，说明下游存储或索引没跟上，而非 QPS 本身高 - 对比不同时间点的
conn和ar：如果连接数稳定但query波动剧烈，更可能是单连接复用下高频小请求（如 chunk 流式读），而非并发用户上涨 - 避免用默认 1s 采样看短时峰值：GridFS 操作有明显 burst 特性，建议用
-i 5（5 秒聚合）降低抖动干扰
真正要统计“每秒多少个文件 upload/download”，必须在应用层埋点：GridFSBucket.openUploadStream() 调用即 +1，stream.on('end') 成功即确认；任何试图从 mongostat 反推文件 QPS 的做法，都会在 chunk 大小变化、驱动版本升级或启用压缩后失效。
