Debian MongoDB性能如何调优

Debian 上 MongoDB 性能调优实操指南

一 硬件与操作系统基础

• 存储优先使用 NVMe SSD，并预留一定 IOPS 余量；内存尽量覆盖热数据 + 索引，避免频繁换页。
• 关闭或优化 NUMA 与 Transparent Hugepage（THP），减少长尾延迟与抖动：
  • GRUB 启动参数示例：GRUB_CMDLINE_LINUX_DEFAULT="quiet numa=off transparent_hugepage=never"，执行 sudo update-grub && sudo reboot 生效；
  • 运行时关闭（若不存在对应路径请先确认内核配置）：
    echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
echo never | sudo tee /sys/kernel/mm/transparent_hugepage/defrag
• 适度配置 Swap（如 2–4GB），并将 vm.swappiness 调低（如 10–30），避免内存紧张时剧烈换页。
• 保持系统与驱动、固件为较新稳定版本，减少 I/O 栈与调度器带来的不确定性。

二 存储引擎与缓存配置

• 使用 WiredTiger 存储引擎，合理设置 cacheSizeGB：通常设为“物理内存的约 50%–60%”，在存在其他服务时适当下调，避免与操作系统 page cache 争抢内存。示例：

  storage:
    wiredTiger:
      engineConfig:
        cacheSizeGB: 8   # 按实际内存调整
  

• 确保 journal.enabled: true，保障崩溃一致性；将 dbPath 指向高性能磁盘（如独立 NVMe 分区）。
• 如仍使用 MMAPv1（不推荐），可考虑 storage.mmapv1.smallFiles: true 降低内存占用，但该引擎已不推荐用于新部署。

三 索引与查询优化

• 为高频查询路径建立复合索引，遵循最左前缀；尽量使用覆盖索引减少回表；避免过多索引（写放大、占用空间）。
• 使用 explain("executionStats") 分析执行计划，关注 totalKeysExamined、totalDocsExamined、executionTimeMillis 等指标，必要时改写查询或调整索引。
• 控制返回数据量：使用 projection 仅返回必要字段，配合 limit()/skip() 实现分页与裁剪。
• 开启并合理设置 慢查询分析（Profiling）：
  • 全局级别：profile: 1, slowms: 200（记录 >200ms 的操作）；
  • 临时会话：db.setProfilingLevel(1, 200)；
  • 建议将 system.profile 设为 capped 集合并控制大小（如 4MB），便于保留近期样本。
• 避免无索引排序、海量 $where/JavaScript、全表更新等昂贵操作。

四 网络与连接、副本集与分片

• 合理设置 net.maxIncomingConnections（如 200–10000），结合应用连接池与压测结果调优，避免连接风暴与句柄耗尽。
• 绑定地址与安全：仅在内网需要时使用 bindIp: 0.0.0.0，并开启 authorization: enabled；对外暴露时配合 TLS 与防火墙策略。
• 副本集用于高可用与读扩展：将读偏好设置为 secondaryPreferred 可分担读负载；关注复制滞后与 oplog 大小。
• 数据规模或并发超出单机承载时引入 分片，按 shard key 均衡分布热点与数据量，避免跨分片聚合与排序。

五 监控、维护与变更流程

• 持续观测：使用 mongostat（吞吐、锁、队列）、mongotop（集合级耗时）与日志中 >100ms 的 COMMAND 记录定位问题；必要时引入 PMM 做可视化与长期趋势分析。
• 日志轮转与容量管理：MongoDB 默认记录 >100ms 的慢查询；可通过 db.runCommand({ logRotate: 1 }) 轮转日志，便于归档分析。
• 索引维护：在数据大量变更后评估 reIndex 或重建策略，避免碎片影响扫描性能；谨慎评估重建窗口与锁影响。
• 变更流程：任何参数调整先在测试环境验证，采用灰度/滚动方式上线，变更前后保留 基线指标（QPS、P95/P99、延迟、IOPS、命中率）与 回滚预案。