node.js 无法监控 mongodb 内存，因其由 mongod 进程独立管理；process.memoryusage() 仅反映 node 进程内存，与 mongodb 无关；应通过 mongostat、db.serverstatus().mem 等直接观测 mongodb 内存。
Node.js 本身不监控 MongoDB 的内存占用——MongoDB 的内存使用是独立于 Node.js 进程的，它由 mongod 进程自身管理（主要用 mmap + page cache），Node.js 只能间接观察或触发相关指标采集。
为什么 process.memoryUsage() 对 MongoDB 无效
这是最常踩的误区：process.memoryUsage() 返回的是当前 Node.js 进程的 V8 堆和系统驻留内存（rss），完全不包含 MongoDB 服务本身的内存。哪怕你在 Node 中用 mongodb 驱动频繁读写，heapUsed 或 rss 上涨也只反映 JS 对象、Buffer、驱动内部缓存等，而非 MongoDB 实例的 RAM 消耗。
- 典型错误：看到 Node 进程 RSS 达到 1.2GB，就认为“MongoDB 占了 1.2GB”，实际可能是 Buffer 未释放或驱动连接池泄漏
- MongoDB 的真实内存压力体现在宿主机
free -m或top中mongod进程的 RES 列，不是 Node 进程 - 若用 Docker，需进容器看
ps aux --sort=-rss | head -5，确认是mongod还是node在吃内存
真正有效的 MongoDB 内存观测方式
要监控 MongoDB 自身内存，必须绕过 Node.js，直接对接 MongoDB 服务端暴露的指标：
- 用
mongostat查实时工作集压力：mongostat --host localhost:27017 -u admin -p pwd --authenticationDatabase admin 1，重点关注netIn/netOut和conn，突增常伴随 page fault 上升（说明内存不足，开始刷盘） - 在
mongoshell 中运行db.serverStatus().mem，返回bits、resident（当前驻留内存 MB）、virtual（虚拟内存 MB）等字段——这才是 MongoDB 真实的内存视图 - 检查
db.stats()中的dataSize与storageSize比值，若远小于 1（如 0.3），说明数据压缩率高，但 page cache 压力未必小；若接近 1 且resident持续上涨，大概率工作集 > 物理内存
Node.js 中可做的间接辅助监控
虽然不能直接读 MongoDB 内存，但 Node.js 可以捕获驱动层信号，提前预警潜在内存压力：
- 监听驱动的
serverHeartbeatSucceeded事件，解析reply.uptimeMillis和reply.mem（仅 MongoDB 6.0+ 且启用enableLocalHostAuthBypass时部分暴露，不推荐依赖） - 定期调用
db.command({ serverStatus: 1 })并提取mem.resident，但注意：该命令本身有开销，生产环境建议间隔 ≥30 秒，且需 admin 权限 - 结合连接池状态：如果
maxPoolSize设为 10，但inUseConnections长期 ≥9，waitingConnections> 0，往往意味着查询变慢 → page fault 上升 → 内存瓶颈已出现
mongo-express 里容易被忽略的配置点
如果你用 mongo-express 做可视化入口，它的配置直接影响你能否看到关键内存指标：
-
ME_CONFIG_MONGODB_ENABLE_ADMIN=true必须开启，否则db.serverStatus()类命令会因权限被拒而返回空或报错not authorized on admin to execute command { serverStatus: 1 } -
maxPoolSize不宜设过高（如 >20），否则 Node 进程rss会因大量 socket 缓冲区堆积虚高，掩盖真实 MongoDB 内存问题 -
allowDiskUse开关只影响聚合操作是否允许落盘，和 MongoDB 自身内存无关；但它能避免因内存超限导致的查询失败，属于“保命”配置，不是监控手段
真正的内存瓶颈永远在 mongod 进程里，而不是 node 进程里。盯着 process.memoryUsage().rss 调优 MongoDB 是方向性错误——先用 mongostat 和 db.serverStatus().mem 定位服务端压力，再回过头看 Node 驱动是否有连接/Buffer 泄漏，顺序不能颠倒。
