分片集群内存易爆因各组件内存叠加且未合理配置：shard节点wiredtiger.cachesizegb需显式设置为单机内存的40%～60%减1gb，mongos和config server需限制连接数并排查泄漏，drop_caches无效。
为什么分片集群内存容易爆满
分片集群不是单个 mongod 实例内存的简单叠加，而是多个角色（mongos、config server、shard 副本集）各自吃内存，且存在叠加效应。比如：wiredTiger.cacheSizeGB 在每个 shard 节点上独立生效，3 个 shard 各配 4GB，光缓存就占掉 12GB；mongos 进程本身虽轻量，但连接数多时线程栈和请求上下文会快速堆积；config server 虽小，但在元数据频繁变更（如 chunk 拆分、迁移）时也会临时吃高内存。
必须优先检查 wiredTiger 缓存配置
这是最常被忽略、也最有效的调节点。默认情况下，MongoDB 不限制缓存，WiredTiger 会动态占用最多 50%（M40+）或 25%（M30 及以下）物理内存，但这个“物理内存”是按单节点算的——在分片集群里，每个 shard 都这么干，总量就失控了。
-
wiredTiger.cacheSizeGB必须显式写死，不能依赖默认值；数值建议设为单节点总内存的 40%～60%，再减去 1GB 余量（例如 16GB 内存机器设cacheSizeGB: 5） - 该参数只对 shard 节点和 config server 有效，
mongos不走 WiredTiger，无需配 - 修改后必须重启对应节点，
db.runCommand({setParameter: 1, wiredTigerEngineConfig: "..."}))是运行时无效的 - 验证是否生效：连到 shard 节点执行
db.serverStatus().wiredTiger.cache["bytes currently in the cache"]，换算成 GB 后应接近配置值
排查 mongos 和 config server 的连接与请求内存
mongos 和 config server 不用 WiredTiger 缓存，但每个客户端连接都会分配线程栈（默认上限 1MB），大量短连接或未关闭的连接会迅速耗尽内存。常见现象是 mongos 进程 RSS 持续上涨，但 db.serverStatus().mem 显示使用很低。
- 查活跃连接数：
db.currentOp({secs_running: {$gt: 0}}).itcount()，若远超预期（比如 >500），说明有连接泄漏 - 限制
mongos最大连接数：启动时加--maxConns 2000参数（不写默认无上限） - 检查应用端是否复用连接池，避免每请求新建
mongos连接 - config server 若出现频繁 chunk 迁移，会导致元数据操作密集，此时观察
db.serverStatus().metrics.repl.apply中的延迟和队列长度
别碰 drop_caches，它治标不治本
执行 echo 3 > /proc/sys/vm/drop_caches 确实能让 free -m 显示的 buff/cache 下降，但这是 Linux 文件系统缓存，不是 MongoDB 进程 RSS 内存。WiredTiger 缓存属于进程私有内存，不受此命令影响；强行刷 cache 反而会让下一次读请求全落盘，引发性能抖动。
真正该看的是 ps aux --sort=-%mem | head -n 10 输出中 mongod 和 mongos 的 %MEM 列，以及 cat /proc/$(pgrep mongod)/status | grep VmRSS 得到的实际物理内存占用（KB）。如果这两项持续走高，说明是进程内内存没释放，得回前面几步找根因。
