线上真实案例:mongo被OOM的一次历险

前言

近期线上平台出现一次故障，mongo数据库被oom了，由于是高可用架构，重新选举了主节点后，继续工作，没想到刚选举完又被oom，mongo重启达到了分钟级别，多个节点被oom后，不能很快的拉起来提供服务，对业务产生了巨大的影响。

分析

•目前从表面来看，有这样几个问题

1.内存128g，在这么高的配置下都发生了OOM，那么看来是有优化空间的，mongo为什么吃了这么多内存 2.为什么启动这么慢

通过表分析，发现有很多大表，其中一个巨大的表占用了110个g，且有频繁的读写。原因是因为有很多冷数据，未做冷热数据分离。

优化1

删除一些历史遗留数据

Mongo优化

从mongoDB 3.2开始支持多种存储引擎，其中默认为 Wired Tiger。我们使用的正是mongodb 3.2版本

MongoDB 不是内存数据库，但是为了提供高效的读写操作存储引擎会最大化的利用内存缓存。

MongoDB 的读写性能都会随着数据量增加达到瓶颈，这其中的根本原因就是内存是否能满足全部的数据。

答案肯定是否定的。

业务的发展超过了机器的配置，那么出现问题只是时间问题，无论在怎么堆机器的配置，数据量的增长就是慢性毒药，只能祈祷毒发身亡那一天晚一点到来。

那么mongo怎么来解决这个问题的呢？

Evict

内存淘汰时机由eviction_target（内存使用量）和eviction_dirty_target（内存脏数据量）来控制，而内核默认是有Evict线程去处理的。

定义表格

那他的默认策略到底是多少呢？

网上说什么各种比例的都有，所以我clone对应版本的源代码，来找答案 ，以下分析基于3.2.13版本

•.全局搜索下关键字和eviction_dirty_target

参数名称	含义	百分比
eviction_target	当Cache的使用量达到了对应的百分比时触发Evict线程淘汰page	80%
eviction_trigger	当Cache的使用量达到了对应的百分比时触发Evict线程和用户线程淘汰page	95%
eviction_dirty_target	当”脏数据“所占Cache达到对应的百分比触发Evict线程淘汰page	5%
eviction_dirty_trigger	当”脏数据“所占Cache达到对应的百分比触发Evict线程和用户线程淘汰page	20%

一般我们会在启动mongo的时候，我们可以通过日志来观察调用wiredtiger_open的参数

细心的同学会发现，日志上打印的参数和我们截图的参数并不符合。比如日志中 eviction=(threads_min=4,threads_max=4)而我们看源代码内容是eviction=(threads_max=8," "threads_min=1) 注：这里的thread线程是上面提到的Evict 线程

带着疑问：我们深入源代码分析下

•

首先进入main函数mongoDbMain

•

main函数末尾会初始化并且监听端口

•

初始化和监听端口里会去检查数据库和版本

•

初始化WiredTigerFactory

•

初始化WiredTigerKVEngine

•

在WiredTigerKVEngine我们能找到答案，这里传入的参数覆盖了上面的配置

这上面的ss，则是启动mongo打印输出的日志。

通过上面的代码，我们可以看到一个关键指标close_idle_time=100000(~28h)，这个时间被硬编码在代码里。

close_idle_time意义如下。在尝试关闭文件句柄之前，文件句柄需要空闲的时间（以秒为单位）。设置为 0 表示不关闭空闲句柄

在Evict线程进行工作的时候，文件句柄在28小时内，一直处于空闲状态才会被关闭。

好处是：增加了命中率，坏处是Evict不及时

对于我们目前的业务来说，这个值太长了，所以我们需要调整它。

如何调整

以下调整建议在业务低峰期进行

•运行中更改

我们在不重启mongo下进行更改，缺点是重启后失效。

db.adminCommand({setParameter: 1, wiredTigerEngineRuntimeConfig: "eviction=(threads_min=1,threads_max=8)"})

•

基于文件修改

systemLog:
destination: file
path: "/var/log/mongodb/mongod.log"
storage:
 dbPath: "/opt"
 wiredTiger:
     engineConfig:
         configString: "eviction_dirty_target=60,async=(enabled=true,ops_max=1024,threads=2)"
processManagement:
fork: true
net:
bindIp: 127.0.0.1
port: 27018

wiredTiger各种参数的解释^[1]

Storage Engine API^[2]

mongoDB高级选项^[3]

总结

问题其实还是在于，冷热数据不分，很多遗留数据，导致系统的不稳定性，出现各种问题。数据量到一定体系的时候，可以使用数据仓库了。

References

[1] wiredTiger各种参数的解释: http://source.wiredtiger.com/2.8.0/group__wt.html#ga9e6adae3fc6964ef837a62795c7840ed
[2] Storage Engine API: https://mongodbsource.github.io/master/globals.html
[3] mongoDB高级选项: https://www.mongodb.com/docs/ops-manager/current/reference/deployment-advanced-options/#storage

本文使用 文章同步助手 同步