引言

背景: 在某一天,運營同事突然發(fā)現運營看板好幾天沒有更新數據了, 然后找了過來?!

這里看似拋出了一個問題 ?

但細想一下, 同時暴露了我們對于線上服務的監(jiān)控未完全覆蓋到!!! 這是致命的!!!

當然, 這篇文章先不討論監(jiān)控的問題, 后面會推出完善的監(jiān)控方案

定位問題

問題拋過來了, 那么我們第一步要怎樣做呢?

拿到問題的第一步, 先理解題意, 這里有幾個關鍵的信息點

第一 : 好幾天, 具體哪一天, 這個后面確認了一個具體的時間點

第二 : 運營看板, 這是重點, 是我們切入問題的關鍵

好了, 有了這兩個關鍵的信息, 我們接下來就開始定位問題代碼了

• 從功能出發(fā), 定位到未更新的表
• 通過表來定位到更新數據的代碼

通過上面兩步找到了問題代碼是某個定時任務

日志搜索

這時按照肌肉記憶, 先是看了代碼有沒有關鍵點的日志輸出, 發(fā)現代碼開始和結束都有打印日志的操作

順藤摸瓜,先登錄到服務器端, grep一波關鍵的日志

發(fā)現當天的 info.log 沒有打印到日志, 這就很奇怪了, 因為這個定時任務的 cron 是每天凌晨1點開始

然后就查了前一天的日志, 發(fā)現有打印到開始的日志, 但是沒有打印結束的日志

然后再去找看有沒有異常的日志, 發(fā)現并沒有

監(jiān)控看板

從日志看出了一點不對勁的味道, 但還沒有足夠的線索定位到具體的問題

這時去查看容器的資源情況

這里觀察的是, 在兩臺容器中, 有一臺容器的 cpu 吃得很緊

另外一臺卻是風平浪靜

從這里可以定位到大概的問題了: CPU負載高

那為什么會造成 CPU 跑那么高呢 ?

ThreadDump

當然有很多方案可以定位 CPU 的瓶頸問題,像使用火焰圖定位(下一篇會使用到)

但從上面的蛛絲馬跡里可以大體定位到是具體的定時任務引起的

這時 threaddump, 并分析了一波線程的運行情況

從整體的報告可以看出有阻塞的線程兩個, 同時有百分之四十是在超時等待

再看看具體被阻塞的線程

看起來是數據庫查詢阻塞

看具體的業(yè)務代碼

分析一下這條 SQL 的變量

入參只有一個就是 classIds 數組:

• 數量很小
• 數量很大
• 數量為 0

數組的分布情況可以為上面幾種

套進去

• 數量很小, 查詢應該很快
• 數量很大, 查詢應該會相對慢一點
• 數量為 0 呢, if 標簽, classIds 數量為 0, 不會 拼接下面的 sql, 也就是會查全表

優(yōu)化

定位到具體的代碼了, 那就是要出優(yōu)化方案了

做法就是當 classIds 的大小為 0 的時候, 不要掃描全表

這里添加 otherwise 分支, classIds 大小為 0 是 and false

重新部署再觀察線上情況, CPU 降了下來

事后反思

為什么會這么久才發(fā)現問題? 而且依賴于業(yè)務側發(fā)現問題

能不能提前感知問題呢?

想了一下, 我們的監(jiān)控更多是在監(jiān)測代碼拋出異常, 對于操作系統(tǒng)的資源缺少監(jiān)控 下一步的優(yōu)化, 對操作系統(tǒng)資源進行監(jiān)控

以上就是線上Spring CPU 高負載解決思路詳解的詳細內容，更多關于線上Spring CPU 高負載的資料請關注腳本之家其它相關文章！

最新評論