MongoDB副本集内存调优

MongoDB副本集的内存调优，本质上是在跟两个“吃内存”的核心模块打交道：WiredTiger存储引擎的缓存和操作系统的文件系统缓存。很多性能问题的根源，不是内存不够，而是默认配置下WiredTiger缓存设得太大，挤压了操作系统缓存的空间，导致磁盘I/O飙升，副本集节点之间出现复制延迟。WiredTiger内部缓存加上文件系统缓存，这两者共同决定了MongoDB工作集的驻留情况。理想状态下，频繁访问的数据和索引应该全部在内存中，但副本集架构下，每个节点承载的读写压力不同，内存分配策略必须区别对待。

WiredTiger缓存由storage.wiredTiger.engineConfig.cacheSizeGB参数控制，默认值是宿主机物理内存的50%减去1GB。这个默认值在专用数据库服务器上看似合理，但在副本集环境中，如果你的服务器同时运行监控代理、备份脚本或其他辅助进程，直接使用默认值就会引发内存争用。更精确的计算公式是：WiredTiger缓存 = (总物理内存 - 操作系统预留内存 - 其他进程所需内存) × 0.9。操作系统预留内存通常建议至少1GB，如果开启了文件系统快照或大页内存，预留量还要增加。例如一台64GB内存的服务器，操作系统预留2GB，其他进程占用2GB，那么WiredTiger缓存应设为 (64 - 2 - 2) × 0.9 = 54GB。这个0.9的系数很关键，它保证了文件系统缓存有足够的空间来存放WiredTiger缓存未覆盖到的数据块。

很多人调优时只盯着cacheSizeGB，却忽略了文件系统缓存的作用。MongoDB使用内存映射文件来访问数据，WiredTiger从磁盘读取的数据块会先经过文件系统缓存。如果你的WiredTiger缓存设置过大，文件系统缓存被压缩到极小，那么每次WiredTiger需要从磁盘读取不在其内部缓存中的数据时，实际上是在进行一次真正的磁盘I/O，而不是从文件系统缓存中获取。这中间的性能差距是数量级的。判断文件系统缓存是否不足，可以观察iostat命令的输出，如果%iowait持续高于10%，同时WiredTiger缓存的脏数据比例不高，那大概率是文件系统缓存被挤压了。解决方案不是加内存，而是适当调低cacheSizeGB，给文件系统缓存腾出至少总内存的10%到15%。

副本集中主节点、从节点和仲裁节点的内存使用模式完全不同，配置不能一刀切。主节点处理所有写入操作，WiredTiger缓存需要容纳活跃的写入数据集，同时还要维护oplog的生成。从节点除了复制写入，还可能承担读请求，它的缓存压力取决于读负载的分布。如果从节点专门用于报表查询或聚合操作，这些操作往往会扫描大量数据，对文件系统缓存的依赖比主节点更高。这种情况下，从节点的cacheSizeGB应该比主节点设得更低一些，主动把内存让给文件系统缓存，以加速全表扫描类的操作。仲裁节点不存储数据，内存配置几乎可以忽略。实际操作中，主节点可以保持cacheSizeGB在内存的60%左右，承担分析类读负载的从节点降到40%到45%，纯备份用途的从节点则可以与主节点保持一致。

从节点通过读取主节点的oplog来同步数据，这个过程对内存的消耗容易被低估。从节点上的复制线程会批量拉取oplog记录，然后应用到本地数据集上。应用oplog时，涉及到的数据页需要被加载到内存中。如果从节点的WiredTiger缓存命中率低，每次应用oplog都可能触发磁盘读取，复制延迟就会逐渐累积。监控db.serverStatus().wiredTiger.cache中的"bytes currently in the cache"和"tracked dirty bytes in the cache"两个指标，如果脏数据比例持续超过20%，说明缓存的淘汰压力大，从节点可能需要更大的WiredTiger缓存来平滑复制过程。但增加缓存的同时，必须同步观察文件系统缓存是否因此被压缩，否则可能适得其反。

索引的访问频率远高于普通数据，理想情况下所有索引应该完全驻留在内存中。可以通过db.collection.stats()查看每个集合的索引总大小，把所有索引大小加起来，与WiredTiger缓存容量做对比。如果索引总大小已经超过缓存容量的70%，说明仅索引本身就快撑满缓存了，数据部分的缓存空间所剩无几。这时有两个选择：一是增加内存并相应调大cacheSizeGB；二是审视索引设计，删除未使用或低效的索引。使用db.collection.aggregate([{$indexStats:{}}])可以分析索引的使用情况，那些accesses.ops字段长期为零的索引就是纯粹的负担。索引优化带来的内存释放效果往往比直接加内存更显著。

WiredTiger的eviction机制负责将缓存中的脏数据页写回磁盘，为新的数据页腾出空间。当缓存接近满载时，eviction线程会加速工作，但如果写入速度持续高于淘汰速度，缓存就会被脏数据占满，导致应用线程被迫参与淘汰操作，吞吐量急剧下降。与eviction相关的几个关键参数值得关注：eviction_target、eviction_trigger和eviction_dirty_target。eviction_target默认80%，表示缓存使用率达到80%时开始淘汰干净页；eviction_trigger默认95%，达到这个阈值时应用线程也会参与淘汰，性能开始恶化。如果你的写入负载是间歇性高峰，可以考虑将eviction_target调低到70%，让淘汰操作提前进行，避免高峰期的突发压力。但调得太低会降低缓存利用率，增加磁盘读取频率，需要结合实际负载曲线来权衡。

在Linux系统上启用透明大页（Transparent Huge Pages）对MongoDB来说几乎总是负优化。透明大页的合并和拆分操作会引入不可预测的延迟抖动，尤其在内存碎片整理时，可能造成几十到几百毫秒的停顿。MongoDB官方明确建议关闭透明大页。检查当前状态可以用cat /sys/kernel/mm/transparent_hugepage/enabled，如果输出包含[always] madvise never，说明透明大页处于启用状态。关闭方法是在/etc/rc.local或systemd启动脚本中加入以下命令：

echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

同时建议在/etc/sysctl.conf中设置vm.zone_reclaim_mode=0，防止NUMA架构下内存回收策略导致的性能问题。这些操作系统层面的调整，对内存调优的最终效果影响很大，但经常被忽视。

内存调优不是一次性操作，需要建立监控闭环。核心监控指标包括：wiredTiger.cache中的"bytes currently in the cache"除以cacheSizeGB得到的缓存使用率；"tracked dirty bytes in the cache"除以缓存总大小得到的脏数据比例；"cache overflow score"这个指标如果持续大于0，说明缓存压力已经溢出。文件系统缓存方面，可以用free -m观察buffers/cache的变化趋势，或者用vmtouch工具直接检测特定数据文件的驻留情况。把这些指标与业务高峰时段的响应时间、复制延迟做关联分析，就能找到当前配置的瓶颈点。调整参数后，至少观察一个完整的业务周期，确认P99延迟和复制延迟没有恶化，才算完成一轮有效的调优。

初始同步（initial sync）是从节点从零开始复制数据的阶段，这个过程会全量扫描主节点的所有数据，对内存的冲击极大。如果从节点的内存配置与主节点相同，初始同步期间大量冷数据涌入，会把原本热数据全部挤出缓存，同步完成后的一段时间内查询性能会非常差。可以在初始同步前临时调低从节点的cacheSizeGB，让文件系统缓存承担更多缓冲角色，同步完成后再恢复原值。另一个特殊场景是批量数据导入，导入过程中产生的大量脏数据可能触发eviction风暴。此时可以临时调高eviction_dirty_target到85%，允许更多脏数据暂留缓存，减少磁盘写入的随机性，导入完成后再调回默认值。

在Kubernetes或Docker环境中运行MongoDB副本集时，内存调优多了一层复杂性。容器的内存限制通过cgroup施加，但WiredTiger的默认cacheSizeGB计算依据的是宿主机的物理内存，而不是容器的内存限制。如果不显式设置cacheSizeGB，WiredTiger会误以为有大量可用内存，导致OOM Killer介入。在容器化部署中，必须根据容器的内存限制来手动计算cacheSizeGB，公式调整为：cacheSizeGB = (容器内存限制 - 1GB) × 0.75。这个0.75的系数比物理机更保守，因为容器内通常还有sidecar进程和系统开销。同时建议设置WiredTiger的cacheSizeGB为整数，避免浮点数在配置解析时出现精度问题。

内存调优的最终目标，是让MongoDB副本集的每个节点在各自的角色下，缓存命中率维持在95%以上，脏数据比例控制在20%以内，同时操作系统层面没有频繁的磁盘交换。达到这个状态后，副本集的读写性能和复制稳定性都会有质的提升，而且这种提升是硬件资源不变的前提下，仅通过参数调整就能实现的。