天天看點
傳回

Linux 運維故障排查思路

1. 背景

有時候會遇到一些疑難雜症，并且監控插件并不能一眼立馬發現問題的根源。這時候就需要登入伺服器進一步深入分析問題的根源。那麼分析問題需要有一定的技術經驗積累，并且有些問題涉及到的領域非常廣，才能定位到問題。是以，分析問題和踩坑是非常鍛煉一個人的成長和提升自我能力。如果我們有一套好的分析工具，那将是事半功倍，能夠幫助大家快速定位問題，節省大家很多時間做更深入的事情。

2. 說明

本篇文章主要介紹各種問題定位的工具以及會結合案例分析問題。

3. 分析問題的方法論

套用5W2H方法，可以提出性能分析的幾個問題

  • What-現象是什麼樣的
  • When-什麼時候發生
  • Why-為什麼會發生
  • Where-哪個地方發生的問題
  • How much-耗費了多少資源
  • How to do-怎麼解決問題

4. cpu

4.1 說明

針對應用程式，我們通常關注的是核心CPU排程器功能和性能。

線程的狀态分析主要是分析線程的時間用在什麼地方，而線程狀态的分類一般分為：

  1. on-CPU：執行中，執行中的時間通常又分為使用者态時間user和系統态時間sys。
  2. off-CPU：等待下一輪上CPU，或者等待I/O、鎖、換頁等等，其狀态可以細分為可執行、匿名換頁、睡眠、鎖、空閑等狀态。

如果大量時間花在CPU上，對CPU的剖析能夠迅速解釋原因；如果系統時間大量處于off-cpu狀态，定位問題就會費時很多。但是仍然需要清楚一些概念：

  • 處理器
  • 核
  • 硬體線程
  • CPU記憶體緩存
  • 時鐘頻率
  • 每指令周期數CPI和每周期指令數IPC
  • CPU指令
  • 使用率
  • 使用者時間／核心時間
  • 排程器
  • 運作隊列
  • 搶占
  • 多程序
  • 多線程
  • 字長

4.2 分析工具

Linux 運維故障排查思路

說明:

  • uptime，vmstat，mpstat，top，pidstat 隻能查詢到cpu及負載的的使用情況。
  • perf可以跟着到程序内部具體函數耗時情況，并且可以指定核心函數進行統計，指哪打哪。

4.3 使用方式

  1. //檢視系統cpu使用情況top 
  2. //檢視所有cpu核資訊mpstat -P ALL 1 
  3. //檢視cpu使用情況以及平均負載vmstat 1 
  4. //程序cpu的統計資訊pidstat -u 1 -p pid 
  5. //跟蹤程序内部函數級cpu使用情況 perf top -p pid -e cpu-clock 

5. 記憶體

5.1 說明

記憶體是為提高效率而生，實際分析問題的時候，記憶體出現問題可能不隻是影響性能，而是影響服務或者引起其他問題。同樣對于記憶體有些概念需要清楚：

  • 主存
  • 虛拟記憶體
  • 常駐記憶體
  • 位址空間
  • OOM
  • 頁緩存
  • 缺頁
  • 換頁
  • 交換空間
  • 交換
  • 使用者配置設定器libc、glibc、libmalloc和mtmalloc
  • LINUX核心級SLUB配置設定器

5.2 分析工具

Linux 運維故障排查思路

說明：

  • free，vmstat，top，pidstat，pmap隻能統計記憶體資訊以及程序的記憶體使用情況。
  • valgrind 可以分析記憶體洩漏問題。
  • dtrace 動态跟蹤。需要對核心函數有很深入的了解，通過D語言編寫腳本完成跟蹤。

5.3 使用方式

  1. //檢視系統記憶體使用情況free -m 
  2. //虛拟記憶體統計資訊vmstat 1 
  3. //檢視系統記憶體情況top 
  4. //1s采集周期，擷取記憶體的統計資訊pidstat -p pid -r 1 
  5. //檢視程序的記憶體映像資訊pmap -d pid 
  6. //檢測程式記憶體問題valgrind --tool=memcheck --leak-check=full --log-file=./log.txt ./程式名 

6. 磁盤IO

6.1 說明

磁盤通常是計算機最慢的子系統，也是最容易出現性能瓶頸的地方，因為磁盤離 CPU 距離最遠而且 CPU 通路磁盤要涉及到機械操作，比如轉軸、尋軌等。通路硬碟和通路記憶體之間的速度差别是以數量級來計算的，就像1天和1分鐘的差别一樣。要監測 IO 性能，有必要了解一下基本原理和 Linux 是如何處理硬碟和記憶體之間的 IO 的。

在了解磁盤IO之前，同樣我們需要了解一些概念，例如：

  • 檔案系統
  • VFS
  • 檔案系統緩存
  • 頁緩存page cache
  • 緩沖區高速緩存buffer cache
  • 目錄緩存
  • inode
  • inode緩存
  • noop調用政策

6.2 分析工具

Linux 運維故障排查思路

6.3 使用方式

  1. //檢視系統io資訊iotop 
  2. //統計io詳細資訊iostat -d -x -k 1 10 
  3. //檢視程序級io的資訊pidstat -d 1 -p pid 
  4. //檢視系統IO的請求，比如可以在發現系統IO異常時，可以使用該指令進行調查，就能指定到底是什麼原因導緻的IO異常perf record -e block:block_rq_issue -ag^Cperf report 

7. 網絡

7.1 說明

網絡的監測是所有 Linux 子系統裡面最複雜的，有太多的因素在裡面，比如：延遲、阻塞、沖突、丢包等，更糟的是與 Linux 主機相連的路由器、交換機、無線信号都會影響到整體網絡，并且很難判斷是因為 Linux 網絡子系統的問題，還是别的裝置的問題，增加了監測和判斷的複雜度。現在我們使用的所有網卡都稱為自适應網卡，意思是說能根據網絡上的不同網絡裝置導緻的不同網絡速度和工作模式進行自動調整。

7.2 分析工具

Linux 運維故障排查思路

7.3 使用方式

  1. //顯示網絡統計資訊netstat -s 
  2. //顯示目前UDP連接配接狀況netstat -nu 
  3. //顯示UDP端口号的使用情況netstat -apu 
  4. //統計機器中網絡連接配接各個狀态個數netstat -a | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' 
  5. //顯示TCP連接配接ss -t -a//顯示sockets摘要資訊ss -s//顯示所有udp socketsss -u -a//tcp,etcp狀态sar -n TCP,ETCP 1 
  6. //檢視網絡IOsar -n DEV 1//抓包以包為機關進行輸出tcpdump -i eth1 host 192.168.1.1 and port 80 //抓包以流為機關顯示資料内容tcpflow -cp host 192.168.1.1 

8. 系統負載

8.1 說明

Load 就是對計算機幹活多少的度量（WikiPedia：the system Load is a measure of the amount of work that a compute system is doing）簡單的說是程序隊列的長度。Load Average 就是一段時間（1分鐘、5分鐘、15分鐘）内平均Load。

8.2 分析工具

Linux 運維故障排查思路

8.3 使用方式

  1. //檢視負載情況uptimetopvmstat 
  2. //統計系統調用耗時情況strace -c -p pid 
  3. //跟蹤指定的系統操作例如epoll_waitstrace -T -e epoll_wait -p pid 
  4. //檢視核心日志資訊dmesg 

9. 火焰圖

9.1 說明

火焰圖（Flame Graph是 Bredan Gregg 建立的一種性能分析圖表，因為它的樣子近似 ?而得名。

火焰圖主要是用來展示 CPU的調用棧。

y 軸表示調用棧，每一層都是一個函數。調用棧越深，火焰就越高，頂部就是正在執行的函數，下方都是它的父函數。

x 軸表示抽樣數，如果一個函數在 x 軸占據的寬度越寬，就表示它被抽到的次數多，即執行的時間長。注意，x 軸不代表時間，而是所有的調用棧合并後，按字母順序排列的。

火焰圖就是看頂層的哪個函數占據的寬度最大。隻要有”平頂”（plateaus），就表示該函數可能存在性能問題。顔色沒有特殊含義，因為火焰圖表示的是 CPU 的繁忙程度，是以一般選擇暖色調。

常見的火焰圖類型有 On-CPU、Off-CPU、Memory、Hot/Cold、Differential等等。

9.2 安裝依賴庫

//安裝systemtap，預設系統已安裝

yum install systemtap systemtap-runtime 

//核心調試庫必須跟核心版本對應，例如：

uname -r 2.6.18-308.el5kernel-debuginfo-2.6.18-308.el5.x86_64.rpmkernel-devel-2.6.18-308.el5.x86_64.rpmkernel-debuginfo-common-2.6.18-308.el5.x86_64.rpm 

//安裝核心調試庫

debuginfo-install --enablerepo=debuginfo search kerneldebuginfo-install --enablerepo=debuginfo search glibc 

9.3 安裝

git clone https://github.com/lidaohang/quick_location.gitcd quick_location 

9.4 CPU級别火焰圖

cpu占用過高，或者使用率提不上來，你能快速定位到代碼的哪塊有問題嗎？

一般的做法可能就是通過日志等方式去确定問題。現在我們有了火焰圖，能夠非常清晰的發現哪個函數占用cpu過高，或者過低導緻的問題。

9.4.1 on-CPU

cpu占用過高，執行中的時間通常又分為使用者态時間user和系統态時間sys。

使用方式：

//on-CPU user

sh ngx_on_cpu_u.sh pid  

//進入結果目錄

cd ngx_on_cpu_u  

//on-CPU kernel

sh ngx_on_cpu_k.sh pid  

//進入結果目錄

cd ngx_on_cpu_k  

//開一個臨時端口 8088

python -m SimpleHTTPServer 8088

//打開浏覽器輸入位址127.0.0.1:8088/pid.svg  

DEMO：

#include <stdio.h> 

#include <stdlib.h> 

void foo3() 

{   

} 

void foo2(){   

  int i;   

  for(i=0 ; i < 10; i++)        

    foo3(); 

} 

void foo1() 

{   

  int i; 

  for(i = 0; i< 1000; i++) 

      foo3(); 

} 

int main(void) 

{   

  int i;   

  for( i =0; i< 1000000000; i++) {       

    foo1();       

    foo2();   

  } 

} 

DEMO火焰圖：

Linux 運維故障排查思路

9.4.2 off-CPU

cpu過低，使用率不高。等待下一輪CPU，或者等待I/O、鎖、換頁等等，其狀态可以細分為可執行、匿名換頁、睡眠、鎖、空閑等狀态。

使用方式：

// off-CPU user

sh ngx_off_cpu_u.sh pid 

//進入結果目錄

cd ngx_off_cpu_u 

//off-CPU kernel

sh ngx_off_cpu_k.sh pid 

//進入結果目錄

cd ngx_off_cpu_k 

//開一個臨時端口8088

python -m SimpleHTTPServer 8088 

//打開浏覽器輸入位址127.0.0.1:8088/pid.svg 

官網DEMO：

Linux 運維故障排查思路

9.5 記憶體級别火焰圖

如果線上程式出現了記憶體洩漏，并且隻在特定的場景才會出現。這個時候我們怎麼辦呢？有什麼好的方式和工具能快速的發現代碼的問題呢？同樣記憶體級别火焰圖幫你快速分析問題的根源。

使用方式：

sh ngx_on_memory.sh pid 

//進入結果目錄

cd ngx_on_memory 

//開一個臨時端口8088

python -m SimpleHTTPServer 8088 

//打開浏覽器輸入位址127.0.0.1:8088/pid.svg 

官網DEMO：

Linux 運維故障排查思路

9.6 性能回退-紅藍差分火焰圖

你能快速定位CPU性能回退的問題麼？如果你的工作環境非常複雜且變化快速，那麼使用現有的工具是來定位這類問題是很具有挑戰性的。當你花掉數周時間把根因找到時，代碼已經又變更了好幾輪，新的性能問題又冒了出來。主要可以用到每次建構中，每次上線做對比看，如果損失嚴重可以立馬解決修複。

通過抓取了兩張普通的火焰圖，然後進行對比，并對差異部分進行标色：紅色表示上升，藍色表示下降。差分火焰圖是以目前（“修改後”）的profile檔案作為基準，形狀和大小都保持不變。是以你通過色彩的差異就能夠很直覺的找到差異部分，且可以看出為什麼會有這樣的差異。

使用方式：

cd quick_location 

//抓取代碼修改前的profile 1檔案

perf record -F 99 -p pid -g -- sleep 30perf script > out.stacks1 

//抓取代碼修改後的profile 2檔案

perf record -F 99 -p pid -g -- sleep 30perf script > out.stacks2 

//生成差分火焰圖

./FlameGraph/stackcollapse-perf.pl ../out.stacks1 > out.folded1

./FlameGraph/stackcollapse-perf.pl ../out.stacks2 > out.folded2

./FlameGraph/difffolded.pl out.folded1 out.folded2 | ./FlameGraph/flamegraph.pl > diff2.svg 

DEMO：

//test.c 

#include <stdio.h> 

#include <stdlib.h> 

void foo3() 

{   

} 

void foo2() 

{   

  int i;   

  for(i=0 ; i < 10; i++) 

      foo3(); 

} 

void foo1() 

{   

  int i;   

  for(i = 0; i< 1000; i++)  

      foo3(); 

} 

int main(void) 

{   

  int i; 

  for( i =0; i< 1000000000; i++) { 

      foo1(); 

      foo2();   

  } 

} 

//test1.c 

#include <stdio.h> 

#include <stdlib.h> 

void foo3() 

{ 

} 

void foo2() 

{ 

  int i; 

  for(i=0 ; i < 10; i++) 

         foo3(); 

} 

void foo1() 

{   

  int i;   

  for(i = 0; i< 1000; i++)      

    foo3(); 

} 

void add() 

{   

  int i;   

  for(i = 0; i< 10000; i++)      

  foo3(); 

} 

int main(void) 

{   

  int i;   

  for( i =0; i< 1000000000; i++) { 

    foo1(); 

    foo2(); 

    add(); 

  } 

} 

DEMO紅藍差分火焰圖：

Linux 運維故障排查思路

10. 案例分析

10.1 接入層nginx叢集異常現象

通過監控插件發現在 2017.09.25 19 點nginx叢集請求流量出現大量的499，5xx狀态碼。并且發現機器cpu使用率升高，目前一直持續中。

10.2 分析nginx相關名額

a) **分析nginx請求流量：

Linux 運維故障排查思路

結論：通過上圖發現流量并沒有突增，反而下降了，跟請求流量突增沒關系。

b) **分析nginx響應時間

Linux 運維故障排查思路

結論：通過上圖發現nginx的響應時間有增加可能跟nginx自身有關系或者跟後端upstream響應時間有關系。

c) **分析nginx upstream響應時間

Linux 運維故障排查思路

結論：通過上圖發現nginx upstream 響應時間有增加，目前猜測可能後端upstream響應時間拖住nginx，導緻nginx出現請求流量異常。

10.3 分析系統cpu情況

a) **通過top觀察系統名額

top

Linux 運維故障排查思路

結論：發現nginx worker cpu比較高

b) **分析nginx程序内部cpu情況

  1. perf top -p pid 

結論：發現主要開銷在free，malloc，json解析上面

10.4 火焰圖分析cpu

a) **生成使用者态cpu火焰圖

//on-CPU user

sh ngx_on_cpu_u.sh pid 

//進入結果目錄

cd ngx_on_cpu_u 

//開一個臨時端口8088

python -m SimpleHTTPServer 8088 

//打開浏覽器輸入位址127.0.0.1:8088/pid.svg 

Linux 運維故障排查思路

結論：發現代碼裡面有頻繁的解析json操作，并且發現這個json庫性能不高，占用cpu挺高。

10.5 案例總結

a) 分析請求流量異常，得出nginx upstream後端機器響應時間拉長

b) 分析nginx程序cpu高，得出nginx内部子產品代碼有耗時的json解析以及記憶體配置設定回收操作

10.5.1 深入分析

根據以上兩點問題分析的結論，我們進一步深入分析。

後端upstream響應拉長，最多可能影響nginx的處理能力。但是不可能會影響nginx内部子產品占用過多的cpu操作。并且當時占用cpu高的子產品，是在請求的時候才會走的邏輯。不太可能是upstram後端拖住nginx，進而觸發這個cpu的耗時操作。

10.5.2 解決方式

遇到這種問題，我們優先解決已知的，并且非常明确的問題。那就是cpu高的問題。解決方式先降級關閉占用cpu過高的子產品，然後進行觀察。經過降級關閉該子產品cpu降下來了，并且nginx請求流量也正常了。之是以會影響upstream時間拉長，因為upstream後端的服務調用的接口可能是個環路再次走回到nginx。

11.參考資料

  • http://www.brendangregg.com/index.html
  • http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html
  • http://www.brendangregg.com/FlameGraphs/memoryflamegraphs.html
  • http://www.brendangregg.com/FlameGraphs/offcpuflamegraphs.html
  • http://www.brendangregg.com/blog/2014-11-09/differential-flame-graphs.html
  • https://github.com/openresty/openresty-systemtap-toolkit
  • https://github.com/brendangregg/FlameGraph
  • https://www.slideshare.net/brendangregg/blazing-performance-with-flame-graphs

【編輯推薦】

  1. 1行代碼實作Python資料分析：圖表美觀清晰，自帶對比功能丨開源
  2. 印度電子商務新規遏制亞馬遜、谷歌等本土稱霸，72小時送出使用者資料
  3. 資料不會說謊 銳捷雲桌面與傳統PC實戰證明力
  4. Linux 核心編碼規範将添加“包容性術語”準則
  5. 取代H.265/HEVC！H.266編解碼标準釋出：視訊清晰度不變、資料量減半
Linux 故障
上一篇: Linux運維故障排查思路
下一篇: java cpu過高排查_運維開發必備：如何排查Linux系統故障？

繼續閱讀