本文介绍了Falcon-Graph模块频繁OOM的排查经过及解决办法。
上篇文章回顾：浅谈Dcoker的安全性支持（下篇）
业务背景
Falcon-Graph负责将监控数据持久化，供用户后期查询、汇总等功能。
4月初，Open-Falcon业务量逐渐上升，由0.29billion counter增长至现在0.32 billion，由此带来graph集群内存占比平均上升8%(now:73%)，机器负载（load:1min）平均上升5%（now:18）。
总结3天现场状况发现在20:00集群内存会整体上升，部分机器会发生OOM现象，同时部分机器会在非固定时间点发生OOM现象。
排查过程
1、排查服务本身
调用go pprof进行服务本身性能分析，在问题现场抓到如下信息：
cpu：
mem:
对比正常状态下发现cpu在各函数分配并无大的变化，但是mem却在上涨。
由于数据流入量是稳定的，因此怀疑在持久化过程中block等问题导致磁盘写入速度下降，内存数据堆积。
go pprof查询block信息如图：
total信息为0，排除该服务有函数block住写入过程。开始着手排查该机器上其它服务
2、排查该机器上其它服务
（1）排查现场发现每天20:00发现清理服务（graph-clean）短时间大量消耗cpu导致load快速上升（>30），如下图：
（2）排查现场并和同事讨论发现数据中转服务（transfer）会有瞬时大量tcp连接+数据校验导致cpu消耗骤增，从而导致load瞬时上升至32。如下图：
解决方案
1、针对graph-clean代码不合理问题
修改graph-clean代码，平均峰值，降低频率，从而降低cpu开销
测试集群测试（已完成）
线上灰度1台机器观察（已完成，已解决短时间大量消耗cpu问题，部署后该机器未发生此问题导致graph服务oom）
线上逐步灰度其它机器（已完成，观察一周未发生此问题导致graph服务oom）
2、针对transfer/graph服务混布
拆开transfer/graph进行单独部署（国际化过程逐步进行拆分）
3、梳理graph代码，根据调优图对不合理数据结构进行修改，降低系统开销。
本文首发于公众号“小米云技术”，点击阅读原文。
