外观
MongoDB CPU内存监控
CPU监控核心指标
系统级CPU指标
- CPU使用率：MongoDB进程占用的CPU百分比，单实例建议不超过70%
- CPU上下文切换：频繁的上下文切换可能导致性能下降
- CPU负载平均值：1分钟、5分钟、15分钟负载，理想值不超过CPU核心数
MongoDB层面CPU指标
- opcounters：操作计数器，包括insert、query、update、delete等操作频率
- opcountersRepl：副本集操作计数器，反映复制延迟
- command：命令执行频率，特别是慢命令
监控工具
- mongostat：实时查看MongoDB进程的CPU使用率
- top/htop：系统级CPU监控
- Prometheus + Grafana：长期监控和可视化
- MongoDB Atlas：云服务内置监控
- Ops Manager：企业级监控解决方案
内存监控核心指标
系统级内存指标
- 物理内存使用率：包括已用内存、缓存和缓冲区
- 交换分区使用率：MongoDB应避免使用交换分区，建议禁用或设置较低阈值
- 页交换速率：频繁的页交换会严重影响性能
MongoDB层面内存指标
- resident：MongoDB进程实际使用的物理内存
- virtual：MongoDB进程分配的虚拟内存
- mapped：映射到内存的文件大小，与数据文件大小相关
- workingSet：工作集大小，反映频繁访问的数据量
工作集管理
- 确保系统有足够内存容纳工作集
- 使用
db.serverStatus().mem查看内存使用情况 - 监控
wiredTiger.cache指标，了解缓存命中率
监控策略与告警设置
监控频率
- 实时监控：1秒间隔（mongostat）
- 长期监控：60秒间隔（Prometheus/Grafana）
- 关键指标：5-10秒间隔
告警阈值设置
CPU告警阈值
| 指标 | 警告阈值 | 严重阈值 |
|---|---|---|
| CPU使用率 | 70% | 90% |
| 上下文切换 | 10000/秒 | 50000/秒 |
| 负载平均值 | CPU核心数 | CPU核心数×2 |
内存告警阈值
| 指标 | 警告阈值 | 严重阈值 |
|---|---|---|
| 物理内存使用率 | 80% | 95% |
| 交换分区使用率 | 10% | 30% |
| WiredTiger缓存使用率 | 80% | 95% |
告警渠道
- 邮件告警
- 短信告警
- 企业微信/钉钉告警
- PagerDuty等专业告警工具
性能优化建议
CPU优化
- 查询优化：创建合适的索引，避免全表扫描
- 连接管理：限制连接数，使用连接池
- 硬件升级：考虑更高主频的CPU或增加核心数
- 读写分离：将读请求分发到从节点
- 分片集群：水平扩展CPU资源
内存优化
- 工作集优化：分析查询模式，优化数据模型
- 索引优化：删除不必要的索引，控制索引大小
- WiredTiger缓存调整：根据系统内存调整
cacheSizeGB参数 - 关闭大页：避免透明大页（THP）导致的性能问题
- 硬件升级：增加物理内存
版本差异
MongoDB 3.6 vs 4.0
- 4.0版本引入了更多内存监控指标
- 4.0版本优化了WiredTiger缓存管理
MongoDB 4.0 vs 4.2
- 4.2版本增强了CPU使用统计
- 4.2版本改进了内存分配算法
MongoDB 4.2 vs 5.0
- 5.0版本引入了实时性能分析工具
- 5.0版本优化了多线程处理
MongoDB 5.0 vs 6.0
- 6.0版本增强了内存使用的可见性
- 6.0版本改进了CPU密集型操作的处理
常见问题（FAQ）
Q1: MongoDB占用过多CPU怎么办？
A1: 首先使用mongostat查看当前操作，然后使用db.currentOp()找出慢操作，分析慢查询日志，优化查询或创建索引。如果是系统级问题，检查是否有其他进程占用CPU资源。
Q2: 如何确定MongoDB的工作集大小？
A2: 可以通过监控wiredTiger.cache.bytes currently in the cache指标，或者使用db.serverStatus().wiredTiger.cache查看缓存使用情况。也可以通过分析访问模式和数据大小来估算。
Q3: MongoDB内存使用率很高正常吗？
A3: MongoDB会尽可能使用系统内存来缓存数据，这是正常行为。关键是监控工作集大小和缓存命中率，确保系统有足够内存容纳工作集，避免频繁的磁盘I/O。
Q4: 为什么MongoDB使用交换分区？
A4: MongoDB应避免使用交换分区。如果发生交换，可能是因为系统内存不足或MongoDB配置的内存过大。建议调整cacheSizeGB参数，或增加系统内存，也可以考虑禁用交换分区。
Q5: 如何监控副本集的CPU内存使用？
A5: 可以使用mongostat --all查看所有节点的指标，或使用Prometheus + Grafana监控整个集群。对于Atlas用户，可以直接使用内置的监控仪表板。
Q6: CPU使用率不高但查询很慢怎么办？
A6: 可能是I/O瓶颈导致的。检查磁盘I/O指标，如iowait、磁盘吞吐量等。优化数据模型，使用更高效的查询模式，或考虑升级存储设备（如使用SSD）。
Q7: 如何优化WiredTiger缓存设置？
A7: 根据系统内存大小调整cacheSizeGB参数，一般建议设置为系统内存的50%-80%，但要预留足够内存给操作系统和其他进程。可以通过监控wiredTiger.cache.hits和wiredTiger.cache.misses来调整缓存大小。
Q8: MongoDB内存泄漏怎么办？
A8: 首先确认是否真的是内存泄漏，检查是否有长期运行的慢查询或未关闭的游标。升级到最新版本，MongoDB团队会定期修复内存泄漏问题。如果问题持续，考虑重启实例并联系MongoDB支持。