当前位置: 首页 > 工具软件 > go-graph > 使用案例 >

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

南宫凡
2023-12-01
本文介绍了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代码,根据调优图对不合理数据结构进行修改,降低系统开销。

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


转载于:https://juejin.im/post/5cecd1256fb9a07f0c46620e

 类似资料: