記一次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代碼，根據調優圖對不合理數據結構進行修改，下降系統開銷。

本文首發於公衆號「小米雲技術」，點擊閱讀原文。