這 8 類問題,SysOM 2.0 OOM 診斷助你快速定位異常 | 龍蜥技術
文/劉馨蔚,系統運維 SIG Contributor
小 A 準備下班時,突然收到雲上專門對接客戶前線同事的電話。“小 A,小 A,一個我們遊戲的大客戶的叢集出了問題,影響了業務,需要緊急排查一下”,小 A 也聽出了緊急,放下包嘆了口氣,心想“剛和老婆說回去吃飯呢,看來趕不上咯”。小 A 立馬回到辦公桌向前線同事瞭解詳細情況,原來這個大客戶雲上 pod 內業務突然不可用,檢查後發現有 OOM Killed 的報警,但是發現 pod 的使用記憶體並沒有到閾值 limit 的 8G,請求排查 OOM 的原因並希望給出相關建議避免同樣情況再次發生。
小 A 詳細瞭解情況後,定位到是和 OOM 相關的問題。這時小 A 突然想到了團隊內開發了針對 OOM 的診斷分析的功能,再向同事確認客戶也安裝了 SysOM 後建議客戶立馬進行 SysOM 中的 OOM 診斷。根據 OOM 診斷後診斷出瞭如下結果:
圖中可以看出發生了兩次 OOM,並且懷疑有記憶體洩漏,核心佔用了近 5G 的記憶體,將這個結果和前線同事對齊後,結合客戶的系統日誌“TCP out of memory.”等字樣,排查出問題的原因是業務接收資料不及時,導致資料駐留在核心中。此時建議客戶最佳化業務程式,及時處理接收佇列中的資料包文,並透過重啟業務止血。
前線的同事紛紛點贊小 A 的排查速度和 SysOM 中診斷功能的省時省力,還讓小 A 趕緊介紹一下 SysOM 的這個 OOM 診斷。小 A 也對這個工具也十分熟悉,就和前線的同事好好介紹了介紹:
OOM(Out of memory) 是日常或生產環境中比較容易碰到的異常,當 OOM 發生時一般伴隨著在核心日誌中列印相關異常資訊和某個程式被 Kill 掉的現象:
test invoked oom-killer: gfp_mask=0x6280ca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), nodemask=(null), order=0, oom_score_adj=0
OOM 發生在 Linux 在整機或 cgroup 剩餘記憶體低於水線時,如果透過記憶體回收、規整等方式都無法滿足記憶體分配操作,便會觸發 OOM killer 流程來強行釋放程式記憶體,如下圖所示:
有一部分小夥伴覺得 OOM 根本不算什麼異常,甚至如果不看日誌的話根本沒有感知到;但是有一部分小夥伴卻深受 OOM 的“迫害”,因為 OOM 可能會導致關鍵業務中斷,甚至系統無法正常執行等現象。SysOM 的 OOM 診斷可以檢測 8 類 OOM 的問題,具體如下圖所示:
當發生了 OOM 的問題時,可以透過 SysOM 的 OOM 檢測來對系統的 OOM 提供快速檢測、分析和提供修復建議。
例如整機記憶體低於水線時,透過 SysOM 的 OOM 診斷可以得到如下介面:
SysOM 檢測頁面給出了 OOM 當時的記憶體情況、發生原因和使用記憶體 TOP 10 的記憶體使用排名,結果表明這是屬於 host 記憶體 limit 造成的 OOM。這種情況下我們可以:
1、先評估使用記憶體多的業務程式記憶體佔用是否合理,必要時最佳化業務程式記憶體申請量。
2、還排查程式 oom_score_adj 設定是否合理,不合理的 oom_score_adj 值會導致程式佔用大量記憶體而不被 kill 掉。
例如 cgroup 發生 OOM 時,透過 OOM 診斷可以得到如下介面:
可以看到是由於程式 test 所在的 cgroup mm_test 發生 OOM,原因為 cgroup 記憶體usage 達到 limit 值(90M)。這種情況下我們能夠比較快速直接的判斷出是 cgroup 記憶體 usage 達到了上限,我們可以調整使用情況或者 cgroup 的記憶體可用上限。除了使用達到 limit,oomcheck 還有檢測 shmem 洩漏導致的 OOM。
總的來說,OOM 主要可以分為整機和 cgroup 級別的異常,SysOM 中的 OOM 診斷可以快速準確的定位到系統發生的 OOM 異常,從而使用者可以根據不同的原因應用不同的方法解決 OOM。
小 A 向前線同事介紹完後,大家都表示以後的問題排查、診斷效率肯定有很大的提升。和同事、客戶都交接好後,小 A 感嘆著 SysOM 對系統、核心的各種診斷能力的健全,省時省力,快速定位到異常問題的同時也能夠指引下一步解決方案。哼著小曲兒回家後,小 A 發現老婆熱的湯還是暖呼呼的呢。
龍蜥大講堂 SysOM 2.0 系列直播 《SysOM 2.0 記憶體相關功能介紹》中講解了記憶體診斷中心功能的基本使用和應用場景,展示了三個記憶體診斷的使用引數和結果分析,也在官網上進行了實時演示。影片回放及 PPT 課件獲取見下:
【PPT 課件獲取】:關注微信公眾號(OpenAnolis),回覆“龍蜥課件” 即可獲取。有任何疑問請隨時諮詢龍蜥助手—小龍(微信:openanolis_assis)。
【影片回放】:影片回放可前往 檢視。
—— 完 ——
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70004278/viewspace-2939286/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 龍蜥利器:系統運維工具 SysAK的雲上應用效能診斷 | 龍蜥技術運維
- SysOM 案例解析:消失的記憶體都去哪了 !| 龍蜥技術記憶體
- SysAK 應用抖動診斷篇—— eBPF又立功了! | 龍蜥技術eBPF
- 今天 4 點,龍蜥自動化運維平臺SysOM 2.0的診斷中心功能介紹 | 第 66-68 期運維
- 全面升級!龍蜥自動化運維平臺 SysOM 2.0 可支援作業系統一站式遷移 | 龍蜥技術運維作業系統
- 等待事件快速定位診斷事件
- 表空間檢測異常的問題診斷
- 在 Linux 核心中診斷網路流量異常問題Linux
- 乾貨演講!龍蜥自動化運維平臺 SysOM 2.0 排程、記憶體相關診斷功能介紹 | 第 70-71 期運維記憶體
- OOM分析之問題定位(二)OOM
- 從新手小白到運維大咖,SysOM 多場景當機例項解析 | 龍蜥技術運維
- Spark —— Spark OOM Error問題排查定位SparkOOMError
- 技術門檻高?來看 Intel 機密計算技術在龍蜥社群的實踐 | 龍蜥技術Intel
- SQL問題診斷SQL
- [jvm]常見的oom異常JVMOOM
- 資料庫異常智慧分析與診斷資料庫
- 用 Arthas 神器來診斷 HBase 異常程式
- 【PHP Whoops】錯誤&異常 診斷元件PHPOOP元件
- 龍蜥開發者說:首次觸電,原來你是這樣的龍蜥社群? | 第 8 期
- 系統運維 SysOM profiling 在雲上環境的應用觀測實踐 | 龍蜥技術運維
- WebSphere Application Server 常見問題及解答:故障診斷WebAPPServer
- 助力Koordinator雲原生單機混部,龍蜥混部技術提升CPU利用率達60%|龍蜥技術
- Java核心技術筆記 異常、斷言和日誌Java筆記
- 必看2:快速定位問題:雲伺服器上dns解析異常怎麼修復伺服器DNS
- RAC系統的問題診斷最佳實踐,及常見問題分析
- eBPF 雙子座:天使 or 惡魔?| 龍蜥技術eBPF
- 前端網路診斷技術方案前端
- 執行緒池OOM異常執行緒OOM
- OOM異常型別總結OOM型別
- GreysJava線上問題診斷工具Java
- 問題診斷和PLSQL方面SQL
- 儲存裝置異常告警,如何秒速定位問題?
- 無線網路異常的一次診斷
- 龍蜥開源核心追蹤利器 Surftrace:協議包解析效率提升 10 倍! | 龍蜥技術協議
- 龍蜥開源Plugsched:首次實現 Linux kernel 排程器熱升級 | 龍蜥技術Linux
- flutter的log過濾,快速定位程式碼異常Flutter
- 跨語言程式設計的探索 | 龍蜥技術程式設計
- iofsstat:幫你輕鬆定位 IO 突高,前因後果一目瞭然 | 龍蜥技術