這篇文章將為大家詳細(xì)講解有關(guān)Linux下故障分析怎么用，小編覺(jué)得挺實(shí)用的，因此分享給大家做個(gè)參考，希望大家閱讀完這篇文章后可以有所收獲。

創(chuàng)新互聯(lián)建站主要從事成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站制作、網(wǎng)頁(yè)設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)淇濱,10多年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專(zhuān)業(yè),歡迎來(lái)電咨詢(xún)建站服務(wù):028-86922220

1、背景

有時(shí)候會(huì)遇到一些疑難雜癥，并且監(jiān)控插件并不能一眼立馬發(fā)現(xiàn)問(wèn)題的根源。這時(shí)候就需要登錄服務(wù)器進(jìn)一步深入分析問(wèn)題的根源。那么分析問(wèn)題需要有一定的技術(shù)經(jīng)驗(yàn)積累，并且有些問(wèn)題涉及到的領(lǐng)域非常廣，才能定位到問(wèn)題。所以，分析問(wèn)題和踩坑是非常鍛煉一個(gè)人的成長(zhǎng)和提升自我能力。如果我們有一套好的分析工具，那將是事半功倍，能夠幫助大家快速定位問(wèn)題，節(jié)省大家很多時(shí)間做更深入的事情。

2、說(shuō)明

本篇文章主要介紹各種問(wèn)題定位的工具以及會(huì)結(jié)合案例分析問(wèn)題。

3、分析問(wèn)題的方法論

套用5W2H方法，可以提出性能分析的幾個(gè)問(wèn)題

•  What-現(xiàn)象是什么樣的

•  When-什么時(shí)候發(fā)生

•  Why-為什么會(huì)發(fā)生

•  Where-哪個(gè)地方發(fā)生的問(wèn)題

•  How much-耗費(fèi)了多少資源

•  How to do-怎么解決問(wèn)題

4、cpu

4.1 說(shuō)明

針對(duì)應(yīng)用程序，我們通常關(guān)注的是內(nèi)核CPU調(diào)度器功能和性能。

線程的狀態(tài)分析主要是分析線程的時(shí)間用在什么地方，而線程狀態(tài)的分類(lèi)一般分為：

a. on-CPU：執(zhí)行中，執(zhí)行中的時(shí)間通常又分為用戶(hù)態(tài)時(shí)間user和系統(tǒng)態(tài)時(shí)間sys。

b. off-CPU：等待下一輪上CPU，或者等待I/O、鎖、換頁(yè)等等，其狀態(tài)可以細(xì)分為可執(zhí)行、匿名換頁(yè)、睡眠、鎖、空閑等狀態(tài)。

如果大量時(shí)間花在CPU上，對(duì)CPU的剖析能夠迅速解釋原因；如果系統(tǒng)時(shí)間大量處于off-cpu狀態(tài)，定位問(wèn)題就會(huì)費(fèi)時(shí)很多。但是仍然需要清楚一些概念：

•  處理器

•  核

•  硬件線程

•  CPU內(nèi)存緩存

•  時(shí)鐘頻率

•  每指令周期數(shù)CPI和每周期指令數(shù)IPC

•  CPU指令

•  使用率

•  用戶(hù)時(shí)間／內(nèi)核時(shí)間

•  調(diào)度器

•  運(yùn)行隊(duì)列

•  搶占

•  多進(jìn)程

•  多線程

•  字長(zhǎng)

4.2 分析工具

說(shuō)明：

•  uptime,vmstat,mpstat,top,pidstat只能查詢(xún)到cpu及負(fù)載的的使用情況。

•  perf可以跟著到進(jìn)程內(nèi)部具體函數(shù)耗時(shí)情況，并且可以指定內(nèi)核函數(shù)進(jìn)行統(tǒng)計(jì)，指哪打哪。

4.3 使用方式

//查看系統(tǒng)cpu使用情況  top  //查看所有cpu核信息  mpstat -P ALL 1  //查看cpu使用情況以及平均負(fù)載  vmstat 1  //進(jìn)程cpu的統(tǒng)計(jì)信息  pidstat -u 1 -p pid  //跟蹤進(jìn)程內(nèi)部函數(shù)級(jí)cpu使用情況  perf top -p pid -e cpu-clock

5、內(nèi)存

5.1 說(shuō)明

內(nèi)存是為提高效率而生，實(shí)際分析問(wèn)題的時(shí)候，內(nèi)存出現(xiàn)問(wèn)題可能不只是影響性能，而是影響服務(wù)或者引起其他問(wèn)題。同樣對(duì)于內(nèi)存有些概念需要清楚：

•  主存

•  虛擬內(nèi)存

•  常駐內(nèi)存

•  地址空間

•  OOM

•  頁(yè)緩存

•  缺頁(yè)

•  換頁(yè)

•  交換空間

•  交換

•  用戶(hù)分配器libc、glibc、libmalloc和mtmalloc

•  LINUX內(nèi)核級(jí)SLUB分配器

5.2 分析工具

說(shuō)明：

•  free,vmstat,top,pidstat,pmap只能統(tǒng)計(jì)內(nèi)存信息以及進(jìn)程的內(nèi)存使用情況。

•  valgrind可以分析內(nèi)存泄漏問(wèn)題。

•  dtrace動(dòng)態(tài)跟蹤。需要對(duì)內(nèi)核函數(shù)有很深入的了解，通過(guò)D語(yǔ)言編寫(xiě)腳本完成跟蹤。

5.3 使用方式

//查看系統(tǒng)內(nèi)存使用情況  free -m  //虛擬內(nèi)存統(tǒng)計(jì)信息  vmstat 1  //查看系統(tǒng)內(nèi)存情況  top  //1s采集周期，獲取內(nèi)存的統(tǒng)計(jì)信息  pidstat -p pid -r 1  //查看進(jìn)程的內(nèi)存映像信息  pmap -d pid  //檢測(cè)程序內(nèi)存問(wèn)題  valgrind --tool=memcheck --leak-check=full --log-file=./log.txt  ./程序名

6、磁盤(pán)IO

6.1 說(shuō)明

磁盤(pán)通常是計(jì)算機(jī)最慢的子系統(tǒng)，也是最容易出現(xiàn)性能瓶頸的地方，因?yàn)榇疟P(pán)離 CPU 距離最遠(yuǎn)而且 CPU 訪問(wèn)磁盤(pán)要涉及到機(jī)械操作，比如轉(zhuǎn)軸、尋軌等。訪問(wèn)硬盤(pán)和訪問(wèn)內(nèi)存之間的速度差別是以數(shù)量級(jí)來(lái)計(jì)算的，就像1天和1分鐘的差別一樣。要監(jiān)測(cè) IO 性能，有必要了解一下基本原理和 Linux 是如何處理硬盤(pán)和內(nèi)存之間的 IO 的。

在理解磁盤(pán)IO之前，同樣我們需要理解一些概念，例如：

•  文件系統(tǒng)

•  VFS

•  文件系統(tǒng)緩存

•  頁(yè)緩存page cache

•  緩沖區(qū)高速緩存buffer cache

•  目錄緩存

•  inode

•  inode緩存

•  noop調(diào)用策略

6.2 分析工具

6.3 使用方式

//查看系統(tǒng)io信息  iotop  //統(tǒng)計(jì)io詳細(xì)信息  iostat -d -x -k 1 10  //查看進(jìn)程級(jí)io的信息  pidstat -d 1 -p  pid  //查看系統(tǒng)IO的請(qǐng)求，比如可以在發(fā)現(xiàn)系統(tǒng)IO異常時(shí)，可以使用該命令進(jìn)行調(diào)查，就能指定到底是什么原因?qū)е碌腎O異常  perf record -e block:block_rq_issue -ag  ^C  perf report

7、網(wǎng)絡(luò)

7.1 說(shuō)明

網(wǎng)絡(luò)的監(jiān)測(cè)是所有 Linux 子系統(tǒng)里面最復(fù)雜的，有太多的因素在里面，比如：延遲、阻塞、沖突、丟包等，更糟的是與 Linux 主機(jī)相連的路由器、交換機(jī)、無(wú)線信號(hào)都會(huì)影響到整體網(wǎng)絡(luò)并且很難判斷是因?yàn)?Linux 網(wǎng)絡(luò)子系統(tǒng)的問(wèn)題還是別的設(shè)備的問(wèn)題，增加了監(jiān)測(cè)和判斷的復(fù)雜度?，F(xiàn)在我們使用的所有網(wǎng)卡都稱(chēng)為自適應(yīng)網(wǎng)卡，意思是說(shuō)能根據(jù)網(wǎng)絡(luò)上的不同網(wǎng)絡(luò)設(shè)備導(dǎo)致的不同網(wǎng)絡(luò)速度和工作模式進(jìn)行自動(dòng)調(diào)整。

7.2 分析工具

7.3 使用方式

//顯示網(wǎng)絡(luò)統(tǒng)計(jì)信息  netstat -s //顯示當(dāng)前UDP連接狀況  netstat -nu  //顯示UDP端口號(hào)的使用情況  netstat -apu  //統(tǒng)計(jì)機(jī)器中網(wǎng)絡(luò)連接各個(gè)狀態(tài)個(gè)數(shù)  netstat -a | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'  //顯示TCP連接  ss -t -a //顯示sockets摘要信息  ss -s  //顯示所有udp sockets  ss -u -a  //tcp,etcp狀態(tài)  sar -n TCP,ETCP 1  //查看網(wǎng)絡(luò)IO  sar -n DEV 1  //抓包以包為單位進(jìn)行輸出  tcpdump -i eth2 host 192.168.1.1 and port 80   //抓包以流為單位顯示數(shù)據(jù)內(nèi)容  tcpflow -cp host 192.168.1.1

8、系統(tǒng)負(fù)載

8.1 說(shuō)明

Load 就是對(duì)計(jì)算機(jī)干活多少的度量（WikiPedia：the system Load is a measure of the amount of work that a compute system is doing）簡(jiǎn)單的說(shuō)是進(jìn)程隊(duì)列的長(zhǎng)度。Load Average 就是一段時(shí)間（1分鐘、5分鐘、15分鐘）內(nèi)平均Load。

8.2 分析工具

8.3 使用方式

//查看負(fù)載情況  uptime  top  vmstat  //統(tǒng)計(jì)系統(tǒng)調(diào)用耗時(shí)情況  strace -c -p pid  //跟蹤指定的系統(tǒng)操作例如epoll_wait  strace -T -e epoll_wait -p pid  //查看內(nèi)核日志信息  dmesg

9、火焰圖

9.1 說(shuō)明

火焰圖（Flame Graph是 Bredan Gregg 創(chuàng)建的一種性能分析圖表，因?yàn)樗臉幼咏??而得名。

火焰圖主要是用來(lái)展示 CPU的調(diào)用棧。

y 軸表示調(diào)用棧，每一層都是一個(gè)函數(shù)。調(diào)用棧越深，火焰就越高，頂部就是正在執(zhí)行的函數(shù)，下方都是它的父函數(shù)。

x 軸表示抽樣數(shù)，如果一個(gè)函數(shù)在 x 軸占據(jù)的寬度越寬，就表示它被抽到的次數(shù)多，即執(zhí)行的時(shí)間長(zhǎng)。注意，x 軸不代表時(shí)間，而是所有的調(diào)用棧合并后，按字母順序排列的。

火焰圖就是看頂層的哪個(gè)函數(shù)占據(jù)的寬度最大。只要有”平頂”（plateaus），就表示該函數(shù)可能存在性能問(wèn)題。顏色沒(méi)有特殊含義，因?yàn)榛鹧鎴D表示的是 CPU 的繁忙程度，所以一般選擇暖色調(diào)。

常見(jiàn)的火焰圖類(lèi)型有On-CPU、Off-CPU、Memory、Hot/Cold、Differential等等。

9.2 安裝依賴(lài)庫(kù)

//安裝systemtap，默認(rèn)系統(tǒng)已安裝  yum install systemtap systemtap-runtime  //內(nèi)核調(diào)試庫(kù)必須跟內(nèi)核版本對(duì)應(yīng)，例如：uname -r 2.6.18-308.el5  kernel-debuginfo-2.6.18-308.el5.x86_64.rpm  kernel-devel-2.6.18-308.el5.x86_64.rpm  kernel-debuginfo-common-2.6.18-308.el5.x86_64.rpm  //安裝內(nèi)核調(diào)試庫(kù)  debuginfo-install --enablerepo=debuginfo search kernel  debuginfo-install --enablerepo=debuginfo  search glibc

9.3 安裝

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

9.4 CPU級(jí)別火焰圖

cpu占用過(guò)高，或者使用率提不上來(lái)，你能快速定位到代碼的哪塊有問(wèn)題嗎？

一般的做法可能就是通過(guò)日志等方式去確定問(wèn)題。現(xiàn)在我們有了火焰圖，能夠非常清晰的發(fā)現(xiàn)哪個(gè)函數(shù)占用cpu過(guò)高，或者過(guò)低導(dǎo)致的問(wèn)題。

9.4.1 on-CPU

cpu占用過(guò)高，執(zhí)行中的時(shí)間通常又分為用戶(hù)態(tài)時(shí)間user和系統(tǒng)態(tài)時(shí)間sys。

使用方式：

//on-CPU user  sh ngx_on_cpu_u.sh pid  //進(jìn)入結(jié)果目錄  cd ngx_on_cpu_u  //on-CPU kernel  sh ngx_on_cpu_k.sh pid  //進(jìn)入結(jié)果目錄  cd ngx_on_cpu_k  //開(kāi)一個(gè)臨時(shí)端口8088  python -m SimpleHTTPServer 8088  //打開(kāi)瀏覽器輸入地址  127.0.0.1:8088/pid.svg

DEMO：

#include   #include   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火焰圖：

9.4.2 off-CPU

cpu過(guò)低，利用率不高。等待下一輪CPU，或者等待I/O、鎖、換頁(yè)等等，其狀態(tài)可以細(xì)分為可執(zhí)行、匿名換頁(yè)、睡眠、鎖、空閑等狀態(tài)。

使用方式：

// off-CPU user  sh ngx_off_cpu_u.sh pid  //進(jìn)入結(jié)果目錄  cd ngx_off_cpu_u  //off-CPU kernel  sh ngx_off_cpu_k.sh pid //進(jìn)入結(jié)果目錄  cd ngx_off_cpu_k  //開(kāi)一個(gè)臨時(shí)端口8088  python -m SimpleHTTPServer 8088  //打開(kāi)瀏覽器輸入地址  127.0.0.1:8088/pid.svg

官網(wǎng)DEMO：

9.5 內(nèi)存級(jí)別火焰圖

如果線上程序出現(xiàn)了內(nèi)存泄漏，并且只在特定的場(chǎng)景才會(huì)出現(xiàn)。這個(gè)時(shí)候我們?cè)趺崔k呢？有什么好的方式和工具能快速的發(fā)現(xiàn)代碼的問(wèn)題呢？同樣內(nèi)存級(jí)別火焰圖幫你快速分析問(wèn)題的根源。

使用方式：

sh ngx_on_memory.sh pid    //進(jìn)入結(jié)果目錄  cd ngx_on_memory  //開(kāi)一個(gè)臨時(shí)端口8088  python -m SimpleHTTPServer 8088  //打開(kāi)瀏覽器輸入地址  127.0.0.1:8088/pid.svg

官網(wǎng)DEMO：

9.6 性能回退-紅藍(lán)差分火焰圖

你能快速定位CPU性能回退的問(wèn)題么？如果你的工作環(huán)境非常復(fù)雜且變化快速，那么使用現(xiàn)有的工具是來(lái)定位這類(lèi)問(wèn)題是很具有挑戰(zhàn)性的。當(dāng)你花掉數(shù)周時(shí)間把根因找到時(shí)，代碼已經(jīng)又變更了好幾輪，新的性能問(wèn)題又冒了出來(lái)。主要可以用到每次構(gòu)建中，每次上線做對(duì)比看，如果損失嚴(yán)重可以立馬解決修復(fù)。

通過(guò)抓取了兩張普通的火焰圖，然后進(jìn)行對(duì)比，并對(duì)差異部分進(jìn)行標(biāo)色：紅色表示上升，藍(lán)色表示下降。差分火焰圖是以當(dāng)前（“修改后”）的profile文件作為基準(zhǔn)，形狀和大小都保持不變。因此你通過(guò)色彩的差異就能夠很直觀的找到差異部分，且可以看出為什么會(huì)有這樣的差異。

使用方式：

cd quick_location  //抓取代碼修改前的profile 1文件  perf record -F 99 -p pid -g -- sleep 30  perf script > out.stacks1  //抓取代碼修改后的profile 2文件  perf record -F 99 -p pid -g -- sleep 30  perf 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   #include   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   #include   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紅藍(lán)差分火焰圖：

10、案例分析

10.1 接入層nginx集群異常現(xiàn)象

通過(guò)監(jiān)控插件發(fā)現(xiàn)在2017.09.25 19點(diǎn)nginx集群請(qǐng)求流量出現(xiàn)大量的499，5xx狀態(tài)碼。并且發(fā)現(xiàn)機(jī)器cpu使用率升高，目前一直持續(xù)中。

10.2 分析nginx相關(guān)指標(biāo)

a) **分析nginx請(qǐng)求流量：

結(jié)論：

通過(guò)上圖發(fā)現(xiàn)流量并沒(méi)有突增，反而下降了，跟請(qǐng)求流量突增沒(méi)關(guān)系。

b) **分析nginx響應(yīng)時(shí)間

結(jié)論：

通過(guò)上圖發(fā)現(xiàn)nginx的響應(yīng)時(shí)間有增加可能跟nginx自身有關(guān)系或者跟后端upstream響應(yīng)時(shí)間有關(guān)系。

c) **分析nginx upstream響應(yīng)時(shí)間

結(jié)論：

通過(guò)上圖發(fā)現(xiàn)nginx upstream 響應(yīng)時(shí)間有增加，目前猜測(cè)可能后端upstream響應(yīng)時(shí)間拖住nginx，導(dǎo)致nginx出現(xiàn)請(qǐng)求流量異常。

10.3 分析系統(tǒng)cpu情況

a) **通過(guò)top觀察系統(tǒng)指標(biāo)

top

結(jié)論：

發(fā)現(xiàn)nginx worker cpu比較高

b) **分析nginx進(jìn)程內(nèi)部cpu情況

perf top -p pid

結(jié)論：

發(fā)現(xiàn)主要開(kāi)銷(xiāo)在free,malloc,json解析上面

10.4 火焰圖分析cpu

a) **生成用戶(hù)態(tài)cpu火焰圖

//test.c  #include   #include   //on-CPU user  sh ngx_on_cpu_u.sh pid  //進(jìn)入結(jié)果目錄  cd ngx_on_cpu_u  //開(kāi)一個(gè)臨時(shí)端口8088  python -m SimpleHTTPServer 8088  //打開(kāi)瀏覽器輸入地址  127.0.0.1:8088/pid.svg

結(jié)論：

發(fā)現(xiàn)代碼里面有頻繁的解析json操作，并且發(fā)現(xiàn)這個(gè)json庫(kù)性能不高，占用cpu挺高。

10.5 案例總結(jié)

a) 分析請(qǐng)求流量異常，得出nginx upstream后端機(jī)器響應(yīng)時(shí)間拉長(zhǎng)

b) 分析nginx進(jìn)程cpu高，得出nginx內(nèi)部模塊代碼有耗時(shí)的json解析以及內(nèi)存分配回收操作

10.5.1 深入分析

根據(jù)以上兩點(diǎn)問(wèn)題分析的結(jié)論，我們進(jìn)一步深入分析。

后端upstream響應(yīng)拉長(zhǎng)，最多可能影響n(yōu)ginx的處理能力。但是不可能會(huì)影響n(yōu)ginx內(nèi)部模塊占用過(guò)多的cpu操作。并且當(dāng)時(shí)占用cpu高的模塊，是在請(qǐng)求的時(shí)候才會(huì)走的邏輯。不太可能是upstram后端拖住nginx，從而觸發(fā)這個(gè)cpu的耗時(shí)操作。

10.5.2 解決方式

遇到這種問(wèn)題，我們優(yōu)先解決已知的，并且非常明確的問(wèn)題。那就是cpu高的問(wèn)題。解決方式先降級(jí)關(guān)閉占用cpu過(guò)高的模塊，然后進(jìn)行觀察。經(jīng)過(guò)降級(jí)關(guān)閉該模塊cpu降下來(lái)了，并且nginx請(qǐng)求流量也正常了。之所以會(huì)影響upstream時(shí)間拉長(zhǎng)，因?yàn)閡pstream后端的服務(wù)調(diào)用的接口可能是個(gè)環(huán)路再次走回到nginx。

關(guān)于“Linux下故障分析怎么用”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，使各位可以學(xué)到更多知識(shí)，如果覺(jué)得文章不錯(cuò)，請(qǐng)把它分享出去讓更多的人看到。