Linux 上 MongoDB 配置的常见性能瓶颈
瓶颈总览
- WiredTiger 缓存与内存压力：缓存过小导致命中率下降、频繁落盘；过大则挤占系统和其他进程内存，引发换页与抖动。常见诱因包括未显式设置 storage.wiredTiger.engineConfig.cacheSizeGB、工作集超出缓存、或容器/共享环境未限制内存边界。
- 索引与查询设计：缺失或低效索引、无 .explain(“executionStats”) 分析、返回字段过多、排序/聚合在内存中膨胀，都会把压力转嫁到 CPU 与 I/O。
- 连接与文件描述符：连接数过多或 ulimit -n/open files 过低，出现 “too many open files/connections”，队列与上下文切换开销陡增。
- 磁盘 I/O 子系统：使用机械盘、未用 XFS、未挂载 noatime/nodiratime、未关闭 Transparent Huge Pages(THP)、写放大（压缩/日志/检查点）叠加，都会把延迟推高。
- Linux 内核与虚拟内存参数：vm.swappiness 偏高、vm.dirty_ratio/background_ratio 不合理，导致写回风暴与抖动；NUMA/调度策略不当也会拉低吞吐。
定位方法与关键指标
- 系统层：用 top/vmstat 看 CPU iowait 与运行队列，iostat -x 1 观察 await、r/s、w/s、util% 是否长期打满；free 与 /proc/meminfo 检查 swap 与脏页；ulimit -a 与 /etc/security/limits.conf 校验文件句柄与进程数；检查 /sys/kernel/mm/transparent_hugepage/ 是否关闭。
- 数据库层：mongostat --all（关注 qr/qw、conn、faults、wiredTiger.cacheUsage）、mongotop（按库/集合看读写耗时）、慢查询日志与 .explain(“executionStats”) 定位扫描与排序瓶颈。
配置层面的典型瓶颈与优化要点
- 内存与缓存
- 显式设置 storage.wiredTiger.engineConfig.cacheSizeGB，通常留出 40%–60% 给系统与其他进程；在容器/共享主机上务必设置容器内存上限，避免 OOM 与降速。
- 避免工作集超出缓存：优化索引、冷热分层、必要时增加内存或做分片。
- 存储与文件系统
- 使用 XFS 并挂载 noatime,nodiratime；在 WiredTiger 下更匹配高并发与高写压场景。
- 关闭 THP：echo never > /sys/kernel/mm/transparent_hugepage/{enabled,defrag}（并做开机持久化）。
- 压缩与 I/O 分离
- 选择 storage.wiredTiger.collectionConfig.blockCompressor：写密集优先 snappy，读密集且存储紧张选 zstd；不可压缩数据用 none。
- 开启 storage.wiredTiger.engineConfig.directoryForIndexes 将索引与数据分目录（多盘可进一步分卷），降低读写互相抢占。
- 多库高 I/O 场景可开启 storage.directoryPerDB，按库隔离 I/O。
- 网络
- 开启 net.compression.compressors（如 snappy/zstd），降低跨机房/云环境带宽与时延成本。
- 连接与文件描述符
- 提升 ulimit -n/open files 与 nproc（如至 100000+），并在 limits.conf 持久化；合理设置应用连接池，避免连接风暴。
- 内核与虚拟内存
- 调低 vm.swappiness（如 10），适度收紧 vm.dirty_background_ratio / vm.dirty_ratio，减少写回抖动与 swap 风险。
按场景快速判断与对策
- 写入慢、iowait 高：优先检查磁盘（是否非 SSD、util 持续 100%）、WiredTiger 压缩是否过重（写密集可改 snappy）、日志/检查点叠加；考虑 XFS + noatime、关闭 THP、分库分卷与索引/数据分离。
- 查询慢、CPU 高：用 .explain(“executionStats”) 查扫描与排序，补齐/改写索引，减少返回字段与内存排序；必要时增加缓存或做分片以缩小工作集。
- 连接报错或吞吐不稳：核查 ulimit -n/open files 与 limits.conf、应用连接池大小与超时；必要时扩容文件句柄与优化连接复用。