分片集群内存泄漏需分层排查：先确认是否真实泄漏（resident持续增长且不回落），再区分WiredTiger缓存、连接堆积或CVE-2025-14847等漏洞导致的协议层泄漏，重点监控mongos节点的畸形包连接与BSON解析调用栈。

分片集群的内存泄漏不能只看单个 mongod 进程，必须区分是 WiredTiger 缓存正常占用、连接/请求上下文堆积，还是真实泄漏（如 CVE-2025-14847 或 JS 引擎未释放）。

先确认是不是真泄漏：看 resident 和 virtual 是否持续增长

在每个 mongos、config server、shard mongod 节点上执行：
db.serverStatus().mem

• resident（单位 MB）：若该值在无负载时段仍每小时上涨 >5%，且不随重启回落，大概率存在泄漏
• virtual 显著高于 resident（比如 3 倍以上）且持续扩大，需警惕堆内存未释放
• 注意排除干扰：WiredTiger cache 占用高是正常的，它属于 db.serverStatus().wiredTiger.cache 下的 bytes currently in the cache，和 mem.resident 是两套内存空间

查 CVE-2025-14847 漏洞利用痕迹：重点盯 mongos 和入口 shard

该漏洞无需认证即可触发，泄漏发生在网络协议解析层，mongos 是第一道网关，也是最常被攻击的目标节点。

• 检查 MongoDB 版本是否在受影响范围内（如 4.4.0–4.4.29、6.0.0–6.0.26 等），用 db.version() 确认
• 查看系统日志是否有大量短连接重置或 malformed BSON 报错（虽然漏洞本身不记日志，但内核 netstat -s | grep -i "failed" 可能显示异常丢包）
• 临时启用 netstat -anp | grep :27017 | wc -l 监控瞬时连接数突增——攻击者常并发发送畸形包，导致连接数毛刺式飙升

定位泄漏源：从 mongos 到 shard 分层抓堆快照

真实泄漏往往集中在某类组件。不要一上来就 dump 全集群，先聚焦可疑节点。

• 对疑似泄漏的 mongos 或 shard mongod 进程，用 gcore <pid> 生成 core 文件（确保 /proc/<pid>/limits 中 Max core file size 不为 0）
• 用 pprof --heap 加载 core（需 MongoDB 编译时带调试符号，或用官方带 gperftools 的包）
• 重点关注调用栈中是否频繁出现 mongo::rpc::OpMsg::parse、mongo::BSONObjBuilder::appendBinData 或 zlib 相关函数——这是 CVE-2025-14847 的典型泄漏路径
• 若看到大量 JSContext 或 V8Heap 分配，说明 $where、mapReduce 或自定义 JS 函数正在累积内存

绕过泄漏继续运行：临时缓解但不可替代升级

发现泄漏后，升级是最根本解法，但在灰度窗口期可做有限控制。

• 对 mongos 节点，加防火墙规则限制来源 IP（ufw deny from x.x.x.x to any port 27017），尤其封掉扫描源区域
• 禁用高风险功能：db.adminCommand({setParameter: 1, javascriptEnabled: false})（影响 $where 和 mapReduce）
• 降低 wiredTigerEngineConfig 的 cacheSizeGB 并重启 shard 节点——不是为治泄漏，而是把泄漏挤到 swap，延缓 OOM；但会明显拖慢查询
• 绝对不要依赖 kill -USR2 或手动 db.fsyncLock() 清内存，WiredTiger 的 cache 释放由引擎自治，外部干预无效

真正难处理的是泄漏点不在你控制的应用逻辑里，而在协议解析或压缩模块——这种问题不会因为加索引或调参消失，必须靠版本升级堵住内存分配路径。补丁发布后，哪怕只升级 mongos 层，也能拦下大部分攻击流量。