前言
近期线上平台出现一次故障，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: 27018wiredTiger各种参数的解释[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
本文使用 文章同步助手 同步
