目录
- 前言
- 1.限制wiredTiger引擎的内存
- 2.释放太过激进的内存占用
- 3.调整MongoDB释放内存的速率
- 4.控制wiredTiger存储引擎的脏页缓存模式
- 5.控制wiredTiger内存中的“间接内存”使用量
- 5.总结
前言
MongoDB 占用内存过多导致服务器崩溃的问题令人十分头疼,这里记录一下 5 种方式解决 MongoDB 占用内存过多的问题
1.限制wiredTiger引擎的内存
参考作者的另外一篇文章,mongodb常用配置,不过需要注意的是,需要注意你的 MongoDB 使用支持 wiredTiger 引擎,也就是 MongoDB3.2 及以后版本,之前的版本使用的是 mmapv1
注意:这种情况下,我们有时通过windows资源管理器可以看到 MongoDB 的内存占用已经超过了设置的值,这种情况怎么解释?答案就是其实超过的部分被写入了硬盘,怎么证明呢?我们可以打开资源监视器,切换到硬盘选项卡,看看MongoDB写入硬盘的速度就知道了。
2.释放太过激进的内存占用
db.adminCommand({
setParameter:1,
tcmallocAggressiveMemoryDecommit:1
})
3.调整MongoDB释放内存的速率
db.adminCommand({
setParameter:1,
tcmallocReleaseRate:5
})
释放率单位为千分之一,即当用户将1000个page(4k)大小的对象给释放后,会触发一个page的内存归还,所以tcmalloc建议配置0 - 10之间来保证系统操作次数,如果资源使用紧张,可将该配置成500+。
原理解释:
MongoDB 使用 tcmalloc 内存分配器将内存分配并释放回系统。通过将参数 tcmallocAggressiveMemoryDecommit 设置为1,可以将空闲内存标记为空闲后立即释放。它既可以在启动时完成,也可以在运行时完成。也可以通过调整 tcmallocReleaseRate 来调整释放内存的速度。
4.控制wiredTiger存储引擎的脏页缓存模式
wiredTiger.cache_dirty_mode是一个MongoDB配置参数,它控制wiredTiger存储引擎的脏页缓存模式。
主要有两种设置:
- inMemory:缓存所有的脏页(更新但未刷新的页面),以便快速提高读取性能。这需要较高的内存,可能会导致超过内存限制。
- onDisk:不缓存脏页,直接写入磁盘。读取性能会略低,但内存消耗小。
一个示例配置如下:
storage:
engine: wiredTiger
wiredTiger:
engineConfig:
#cache_dirty_mode: inMemory # 缓存脏页在内存中
cache_dirty_mode: onDisk # 脏页不缓存,直接刷新到磁盘
通过测试,使用cache_dirty_mode 设置为onDisk,MongoDB的内存使用量可以降低20-30%。
所以,如果MongoDB的内存使用超出了你的预期或者配置的限制,设置 cache_dirty_mode 为onDisk是一个简单有效的优化方式。这会牺牲一定的写入性能(大约10%左右下降),以此换取较小的内存开销。
5.控制wiredTiger内存中的“间接内存”使用量
wiredTiger.cache_overhead是MongoDB中一个重要的内存优化参数。它控制wiredTiger内存中的“间接内存”使用量。
所谓“间接内存”是指WiredTiger内部用于管理缓存和数据的内存开销,不直接用于缓存数据页面。这部分内存占总内存的一个比例,默认为8%。
cache_overhead参数可以设置这个比例,语法如下:
storage:
engine: wiredTiger
wiredTiger:
engineConfig:
cache_overhead: 3 # 间接内存占3%
将cache_overhead设置为3%,可以减少默认的“间接内存”使用量一半,释放出更多内存用于缓存数据页面。
经测试,将cache_overhead从默认的8%设置为3-5%可以使MongoDB总体内存使用量下降10%左右,且不会导致明显的性能损失。
所以,如果你的MongoDB内存使用量超出预期,将wiredTiger.cache_overhead设置为3-5%是一个简单有效的优化手段。它可以从WiredTiger的内部管理内存中释放出一部分,分配给数据缓存使用,以此来调整和控制MongoDB的总体内存开销。
注意:cache_dirty_mode 和cache_overhead是MongoDB3.4的参数,在3.2中不可用
5.总结
tcmallocReleaseRate 参数有的 MongoDB 版本不支持,作者的3.2版本就不支持,目前在使用前其他方式。不论用什么方式控制,我们的最终目的都是服务器不要崩溃,能够正常的提供服务,上面的参数只是推荐,读者可以根据自己的机器自行调参。回见~