Ubuntu系统MongoDB资源占用高怎么办 - 问答

Ubuntu上MongoDB资源占用高的定位与优化

一、先快速定位占用来源

查看进程与系统内存概况：
- 进程RSS：top -p $(pidof mongod) 或 htop，关注 RES（常驻内存）与 %CPU。
- 系统层面：free -h，注意 Linux 会把大量文件页计入 buff/cache，判断可用内存应看 available 列，避免把 cache 误判为内存吃紧。必要时用 sar -r/sar -W 观察内存与换页趋势。
查看 MongoDB 内部指标：
- 物理内存：db.serverStatus().mem（关注 resident、virtual）。
- 存储引擎缓存：db.serverStatus().wiredTiger.cache（关注 bytes currently in the cache、bytes dirty in the cache 及 eviction 相关阈值）。
- 连接与请求：db.serverStatus().connections（当前/可用连接数），db.serverStatus().tcmalloc（tcmalloc 未归还内存，如 pageheap_free_bytes + total_free_bytes）。
- 实时与历史：mongostat（观察 dirty、used、**miss 等）、mongotop`（按集合看读写耗时）。

二、常见根因与对应处置

WiredTiger 缓存命中与淘汰压力
- 现象：缓存使用接近或超过 eviction_trigger=95%，脏页超过 eviction_dirty_trigger=20%，请求出现阻塞与抖动。
- 处置：为缓存设置上限（见下一节配置），优化慢查询与索引减少换入换出；必要时升级内存规格。
连接与请求开销过大
- 现象：连接数高、线程栈与内核网络缓冲占用上升，聚合/排序临时缓冲增多。
- 处置：控制总连接数（应用连接池、服务端 net.maxIncomingConnections），优化聚合与排序（加索引、allowDiskUse:true），减少大结果集返回。
tcmalloc 未及时归还内存
- 现象：db.serverStatus().tcmalloc 显示大量未归还内存，RSS 长时间不回落。
- 处置：在支持的环境开启/调优 tcmallocAggressiveMemoryDecommit、tcmallocReleaseRate（低峰期操作，逐步调大并观察性能影响）。
索引与执行计划
- 现象：无索引导致全表扫描、PlanCache 占用高、创建索引期间内存峰值明显。
- 处置：建立复合索引、用 explain("executionStats") 验证执行计划；索引构建尽量错峰，避免并发创建多个大索引；必要时清理/重建碎片化索引。
数据模型与聚合内存
- 现象：文档过大、嵌套过深、聚合阶段内存超限。
- 处置：精简文档结构、拆分大聚合、在聚合中使用 allowDiskUse:true 或将大聚合拆分为多阶段任务。

三、关键配置与系统优化

限制 WiredTiger 缓存
- 自 MongoDB 3.4 起，WiredTiger 默认缓存为“RAM 的 50% 减去 1GB”与“256MB”取较大者；在内存较小的主机上可显式下调，避免挤占系统与其他服务。
- 配置示例（YAML，单位 GB，支持小数）：
```
storage:
  wiredTiger:
    engineConfig:
      cacheSizeGB: 1.5   # 依据总内存与业务负载调整
```
- 注意：部分云托管实例的 CacheSize 为规格内存的约 60% 且不可修改，需在应用侧与连接数上优化。
连接与网络
- 适度下调 net.maxIncomingConnections，避免每个连接带来的线程栈与内核缓冲开销；结合应用连接池（如每个服务 20–50 长连接）控制总连接数在 1000 以内更稳。
查询与索引
- 为高频查询路径建立合适的复合索引，避免无索引扫描与内存排序；用 explain("executionStats") 与 mongostat/mongotop 持续验证优化成效。
操作系统层面
- 适度提高文件描述符限制（如 ulimit -n 20000），避免“too many open files”。
- 可选：禁用透明大页（THP）以减少内存管理与页分配抖动：
```
echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
echo never | sudo tee /sys/kernel/mm/transparent_hugepage/defrag
```
- 监控与诊断：持续使用 mongostat、mongotop，必要时引入 PMM 等可视化监控。

四、按资源维度的处置清单

资源维度	快速判断	立即动作	验证与注意
内存	`resident` 高、`wiredTiger.cache` 接近 95% 或脏页超过 20%	下调 `storage.wiredTiger.engineConfig.cacheSizeGB`；优化慢查询与索引；错峰建索引	观察 `mongostat` 的 dirty/used 回落、请求 P95 延迟下降
CPU	`mongostat` 显示高 `qr/qw`、高 `faults`、CPU 持续打满	为热点查询加索引、改写聚合、减少大结果集；必要时水平扩展	用 `explain` 与慢查询日志确认改进效果
连接数	`connections.current` 接近上限、线程栈与网络缓冲占用高	降低应用连接池与 `net.maxIncomingConnections`，合并短连接	观察连接创建速率与超时率是否下降
磁盘 IO	`mongostat` `page_faults` 高、`wiredTiger` 读写吞吐大	使用 SSD、优化索引与查询、避免无索引扫描	观察 `bytes_read/written_from_cache` 与磁盘 util 是否改善
聚合/排序	聚合报错或 P95 高、临时空间不足	在聚合中启用 `allowDiskUse:true`，拆分阶段与结果集	大聚合尽量在从节点或离线窗口执行

以上步骤覆盖了定位、根因、配置与系统层面的关键做法。优先从“缓存与连接”两大可控项入手，配合索引与查询优化，通常即可显著降低资源占用并恢复稳定性。

0 赞

0 踩