線上問題排查
技術標籤：後端
線上問題排查
參考文章：
Linux top命令的用法詳細詳解
對cpu與load的理解及線上問題處理思路解讀
騰訊阿里都問過：線上伺服器CPU佔用率高如何排查定位問題？
0.常見問題
1、你這個專案遇到的最大挑戰是什麼？如何解決的？
2、如果線上發生了報警你回如何排查呢？
3、你有解決過什麼線上問題嗎？
4、能列舉幾個你知道的排查Linux伺服器線上問題的命令嗎？
1、線上伺服器Load飆高如何排查？ 。。。
2、線上伺服器CPU佔用率高如何排查？ 主要排查GC和死迴圈
3、線上伺服器頻繁發生Full GC如何排查？ jstat命令，檢視java堆記憶體使用情況
4、線上伺服器發生死鎖如何排查？ jstack命令，檢視堆疊資訊，裡面會出現
Found one Java-level deadlock
1.伺服器效能指標
- QPS: 峰值時間每秒請求次數（每天80%的訪問集中在20%的時間，這20%的時間叫做峰值時間）
- TPS: 每秒處理的事務數（請求到server，server返回響應，這一個來回就是一個完整的事務）
- RT: 系統對請求作出響應的時間，即一次請求耗時
- LOAD： 系統負載,即：處在執行狀態和正在等待狀態的程序數（程序中的核心級執行緒也會被視作不同的程序）
- PV： 頁面訪問次數
- UV：訪客數（去重複的）
關於LOAD的幾個排查法則：
需要進行排查法則：load average 佔CPU邏輯核數的0.7時，需要開始進行是否有線上問題的排查了；
現在就要修復法則：load average 佔CPU邏輯核數的1.0時，需要立即開始排查了，否則可能收到上級的電話；
凌晨三點半鍛鍊身體法則：load average 佔CPU邏輯核數的5.0時，嚴重超負荷運轉，將失去睡眠，還要在會議上報告問題發生原因。
關於top命令實時監控系統資源相關資訊的 結果檢視： 
# 第一行 top - 10:40:52 up 207 days, 9:19, 9 users, load average: 11.60, 8.30, 7.21 # 10:40:52— 當前系統時間 # 207 days, 9:19, — 系統已經連續運行了207天9小時19分鐘 # 9 users — 當前有9個使用者登入系統 # load average: 11.60, 8.30, 7.21 — load average後面的三個數分別是1分鐘、5分鐘、15分鐘的負載情況。# 第二行 Tasks: 902 total, 13 running, 878 sleeping, 11 stopped, 0 zombie # Tasks — 任務（程序），系統現在共有902個程序，其中處於執行中的有13個，878個在休眠（sleep），stoped狀態的有11個，zombie狀態（殭屍）的有0個。什麼是IOWait:：# 第三行：CPU狀態 %Cpu(s): 11.6 us, 4.8 sy, 0.0 ni, 83.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st # 11.6% us — 使用者空間佔用CPU的百分比。 # 4.8% sy — 核心空間佔用CPU的百分比。 # 0.0 % ni — 改變過優先順序的程序佔用CPU的百分比 # 0.0% id — 空閒CPU百分比 # 0.0% wa — IO等待佔用CPU的百分比 # 0.0% hi — 硬中斷（Hardware IRQ）佔用CPU的百分比 # 0.0% si — 軟中斷（Software Interrupts）佔用CPU的百分比Linux下CPU共有4種狀態：us(使用者態)、sy(核心態)、id(空閒態)、iowait(io等待)。
'iowait' is the percentage of time the CPU is idle AND there is at least one I/O in progress.![]()
# 第四行：記憶體狀態 KiB Mem : 26385964+total, 19836739+free, 29996252 used, 35496008 buff/cache # 26385964+total — 實體記憶體總量 # 29996252 used — 使用中的記憶體總量 # 19836739+free — 空閒記憶體總量 # 35496008 buff/cache — 快取的記憶體量# 第五行： Swap分割槽，一塊特殊的硬碟空間。虛擬記憶體中發生缺頁中斷而又沒有充足的實體記憶體時，就會用到該分割槽。 KiB Swap: 67108860 total, 7532360 free, 59576500 used. 23266046+avail Mem # 67108860 total — 交換區總量 # 59576500 used — 使用的交換區總量 # 7532360 free — 空閒交換區總量 # 23266046+avail Mem — 緩衝的交換區總量
2.Linux下相關的命令操作
- 檢視系統服務列表： chkconfig --list
- 當前執行程序狀態： ps -aux
- 根據程序名稱查詢程序ID: ps -ef | grep processName
- 將程序的堆疊資訊寫入log: jstack pid > s.log (jstack是一個java工具)
- 實時監控指定程序：top -p pid ; 監控指定程序下個各執行緒情況 top -Hp pid
- 追蹤執行緒、程序： strace -p pid(執行緒id), strace -fp pid(程序id)
- 檢視堆記憶體使用情況：jstat -gcutil pid 1000 1000 ，每隔1s列印一次堆記憶體使用情況，列印1000次（可結合MAT分析工具）
- 系統CPU統計: /proc/stat
- 程序CPU統計：/proc/{pid}/stat
- 執行緒CPU統計： /proc/{pid}/task/{threadid}/stat
3.Java應用load高的幾種原因總結
3.1 這裡總結一下load高常見的、可能的一些原因：
- 死迴圈或者不合理的大量迴圈操作，如果不是迴圈操作，按照現代cpu的處理速度來說處理一大段程式碼也就一會會兒的事，基本對能力無消耗
- 頻繁的YoungGC （針對青年區,Eden和Survivor）
- 頻繁的FullGC (針對整個堆)
- 高磁碟IO
- 高網路IO
3.2 線上遇到問題的時候首先不要慌，因為大部分load高的問題都集中在以上幾個點裡面，以下分析問題的步驟或許能幫你整理思路：
排查過程圖示：- top先檢視CPU使用情況：us與id的佔比情況，目的是確認load高是否高CPU起的
- 如果是高CPU引起的，那麼確認一下是否gc引起的，jstat命令 + gc日誌基本就能確認
- gc引起的高CPU直接jstack dump堆疊資訊，非gc引起的分析執行緒堆疊
- 如果不是高cpu引起的，檢視磁碟io佔比（wa），如果是，那麼打執行緒堆疊分析是否有大量的檔案io
- 如果不是高cpu引起的，且不是磁碟io導致的，檢查各依賴子系統的呼叫耗時，高耗時的網路呼叫很可能是罪魁禍首
- 最後還是不行，當束手無策時，jstack列印堆疊多分析分析吧，或許能靈光一現能找到錯誤原因。
4.實戰記錄
本地防丟失： 騰訊阿里都問過：線上伺服器CPU佔用率高如何排查定位問題？.pdf
5.記憶
load高可能的原因？死迴圈大量迴圈、頻繁YoungGC、頻繁FullGC、磁碟和網路io.
排查思路，見排查過程圖。
線上問題案例？死鎖(jstack)、FullGC(jstat)