wiredtiger缓存大小应显式配置为可用内存的50%~60%，ssd可上探至70%、机械盘≤50%，并确保wiredtiger缓存+os文件缓存+mongodb进程开销总和≤85%物理内存，避免oom或io抖动。
WiredTiger缓存大小设多少才不浪费也不卡顿
WiredTiger默认把50%物理内存当缓存用，但实际业务中这个值常导致系统OOM或IO抖动——尤其当机器还跑着其他服务时。关键不是“够不够”，而是“热数据能不能稳住”。
-
storage.wiredTiger.engineConfig.cacheSizeGB必须显式配置，不能依赖默认值；生产环境建议设为可用内存的50%~60%，SSD机器可上探至70%，机械盘必须压到≤50% - 通过
db.serverStatus().wiredTiger.cache实时看"bytes currently in the cache"是否长期 >90%"maximum bytes configured"；超了就说明缓存吃紧，不是加内存，而是该调小cacheSizeGB避免触发OS级swap - 别和系统缓存抢资源：WiredTiger缓存 + OS文件缓存 + MongoDB进程自身开销，三者总和建议控制在物理内存的85%以内
压缩算法选Snappy还是Zstd？看写入吞吐还是读取延迟
7.0默认仍用Snappy，但Zstd在多数场景下更优——尤其当你有大量文本/JSON字段且CPU不紧张时。
- 启用Zstd需启动时加参数：
--wiredTigerCollectionBlockCompressor=zstd或在mongod.conf中配storage.wiredTiger.collectionConfig.blockCompressor: zstd - Snappy压缩率低（约2~3x）、CPU开销小；Zstd压缩率高（4~6x）、CPU占用略高但现代服务器基本无感；实测Zstd在日志类集合上可降低30%磁盘IO压力
- 注意：压缩算法只影响集合数据块，索引不压缩；若集合含大量二进制字段（如Base64图片），Zstd收益会打折扣，此时可考虑
none关闭压缩
eviction线程数和淘汰目标怎么配才不拖慢写入
缓存淘汰太慢，脏页堆积 → 写入阻塞；淘汰太快，频繁刷盘 → IO毛刺。这组参数必须协同调。
-
storage.wiredTiger.engineConfig.evictionThreads建议按CPU核数设：16核以下设2，16~32核设4，32核以上最多设8；超过8线程反而引发锁竞争 -
storage.wiredTiger.engineConfig.evictionTarget控制“主动清理阈值”，默认80；若观察到pages evicted by age持续飙升，说明老化淘汰过多，应调高至85~90，让缓存更“懒”一点 - 禁用
evictionTrigger（已废弃），它在7.0中无效；所有淘汰行为由evictionTarget和后台线程协同驱动
副本集里要不要给Secondary单独调IO参数
要，而且必须调。Secondary同步压力大、读流量高，但默认配置和Primary完全一样，容易造成从节点IO瓶颈拖累整个复制链路。
- Secondary节点建议单独加大
cacheSizeGB（比Primary高1~2GB），因为要同时扛同步+读请求，热数据集更大 - Secondary可关闭journal（
storage.journal.enabled: false），因为它不处理写请求，journal纯属冗余开销；但前提是你的复制延迟监控到位，否则故障切换时可能丢数据 - 务必检查
replSetGetStatus中的optimeDate和lastHeartbeatRecv差值；若差值持续 >5s，优先查IO队列深度（iostat -x 1看 %util 和 await），而不是盲目加CPU
cacheSizeGB 和 journal 配置，很多人直接复用Primary模板，结果同步延迟悄悄涨到分钟级才报警。
