记一次Open-Falcon-Graph频繁OOM问题排查

本文介绍了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现象。

排查过程

一、排查服务自己

调用go pprof进行服务自己性能分析，在问题现场抓到以下信息：

cpu：

mem:

对比正常状态下发现cpu在各函数分配并没有大的变化，可是mem却在上涨。

因为数据流入量是稳定的，所以怀疑在持久化过程当中block等问题致使磁盘写入速度降低，内存数据堆积。

go pprof查询block信息如图：

total信息为0，排除该服务有函数block住写入过程。开始着手排查该机器上其它服务

二、排查该机器上其它服务

（1）排查现场发现天天20:00发现清理服务（graph-clean）短期大量消耗cpu致使load快速上升（>30），以下图：

（2）排查现场并和同事讨论发现数据中转服务（transfer）会有瞬时大量tcp链接+数据校验致使cpu消耗骤增，从而致使load瞬时上升至32。以下图：

解决方案

一、针对graph-clean代码不合理问题

• 修改graph-clean代码，平均峰值，下降频率，从而下降cpu开销

• 测试集群测试（已完成）

• 线上灰度1台机器观察（已完成，已解决短期大量消耗cpu问题，部署后该机器未发生此问题致使graph服务oom）

• 线上逐步灰度其它机器（已完成，观察一周未发生此问题致使graph服务oom）

二、针对transfer/graph服务混布

• 拆开transfer/graph进行单独部署（国际化过程逐步进行拆分）

三、梳理graph代码，根据调优图对不合理数据结构进行修改，下降系统开销。

本文首发于公众号“小米云技术”，点击阅读原文。