线上真实案例: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 的读写性能都会随着数据量增加达到瓶颈，这其中的根本原因就是内存是否能满足全部的数据。

答案肯定是否定的。

业务的发展超过了机器的配置，那