溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
小編給大家分享一下Linux問題故障定位的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！
有時候會遇到一些疑難雜癥，并且監(jiān)控插件并不能一眼立馬發(fā)現(xiàn)問題的根源。這時候就需要登錄服務器進一步深入分析問題的根源。那么分析問題需要有一定的技術經(jīng)驗積累，并且有些問題涉及到的領域非常廣，才能定位到問題。所以，分析問題和踩坑是非常鍛煉一個人的成長和提升自我能力。如果我們有一套好的分析工具，那將是事半功倍，能夠幫助大家快速定位問題，節(jié)省大家很多時間做更深入的事情。
本篇文章主要介紹各種問題定位的工具以及會結合案例分析問題。
套用5W2H方法，可以提出性能分析的幾個問題
What-現(xiàn)象是什么樣的
When-什么時候發(fā)生
Why-為什么會發(fā)生
Where-哪個地方發(fā)生的問題
How much-耗費了多少資源
How to do-怎么解決問題
針對應用程序，我們通常關注的是內核CPU調度器功能和性能。
線程的狀態(tài)分析主要是分析線程的時間用在什么地方，而線程狀態(tài)的分類一般分為：
a. on-CPU：執(zhí)行中，執(zhí)行中的時間通常又分為用戶態(tài)時間user和系統(tǒng)態(tài)時間sys。
b. off-CPU：等待下一輪上CPU，或者等待I/O、鎖、換頁等等，其狀態(tài)可以細分為可執(zhí)行、匿名換頁、睡眠、鎖、空閑等狀態(tài)。
如果大量時間花在CPU上，對CPU的剖析能夠迅速解釋原因；如果系統(tǒng)時間大量處于off-cpu狀態(tài)，定位問題就會費時很多。但是仍然需要清楚一些概念：
處理器
核
硬件線程
CPU內存緩存
時鐘頻率
每指令周期數(shù)CPI和每周期指令數(shù)IPC
CPU指令
使用率
用戶時間／內核時間
調度器
運行隊列
搶占
多進程
多線程
字長
說明:
uptime,vmstat,mpstat,top,pidstat只能查詢到cpu及負載的的使用情況。
perf可以跟著到進程內部具體函數(shù)耗時情況，并且可以指定內核函數(shù)進行統(tǒng)計，指哪打哪。
//查看系統(tǒng)cpu使用情況top//查看所有cpu核信息mpstat -P ALL 1//查看cpu使用情況以及平均負載vmstat 1//進程cpu的統(tǒng)計信息pidstat -u 1 -p pid//跟蹤進程內部函數(shù)級cpu使用情況perf top -p pid -e cpu-clock
內存是為提高效率而生，實際分析問題的時候，內存出現(xiàn)問題可能不只是影響性能，而是影響服務或者引起其他問題。同樣對于內存有些概念需要清楚：
主存
虛擬內存
常駐內存
地址空間
OOM
頁緩存
缺頁
換頁
交換空間
交換
用戶分配器libc、glibc、libmalloc和mtmalloc
LINUX內核級SLUB分配器
說明：
free,vmstat,top,pidstat,pmap只能統(tǒng)計內存信息以及進程的內存使用情況。
valgrind可以分析內存泄漏問題。
dtrace動態(tài)跟蹤。需要對內核函數(shù)有很深入的了解，通過D語言編寫腳本完成跟蹤。
//查看系統(tǒng)內存使用情況free -m//虛擬內存統(tǒng)計信息vmstat 1//查看系統(tǒng)內存情況top//1s采集周期，獲取內存的統(tǒng)計信息pidstat -p pid -r 1//查看進程的內存映像信息pmap -d pid//檢測程序內存問題valgrind --tool=memcheck --leak-check=full --log-file=./log.txt ./程序名
磁盤通常是計算機最慢的子系統(tǒng)，也是最容易出現(xiàn)性能瓶頸的地方，因為磁盤離 CPU 距離最遠而且 CPU 訪問磁盤要涉及到機械操作，比如轉軸、尋軌等。訪問硬盤和訪問內存之間的速度差別是以數(shù)量級來計算的，就像1天和1分鐘的差別一樣。要監(jiān)測 IO 性能，有必要了解一下基本原理和 Linux 是如何處理硬盤和內存之間的 IO 的。
在理解磁盤IO之前，同樣我們需要理解一些概念，例如：
文件系統(tǒng)
VFS
文件系統(tǒng)緩存
頁緩存page cache
緩沖區(qū)高速緩存buffer cache
目錄緩存
inode
inode緩存
noop調用策略
//查看系統(tǒng)io信息iotop//統(tǒng)計io詳細信息iostat -d -x -k 1 10//查看進程級io的信息pidstat -d 1 -p pid//查看系統(tǒng)IO的請求，比如可以在發(fā)現(xiàn)系統(tǒng)IO異常時，可以使用該命令進行調查，就能指定到底是什么原因導致的IO異常perf record -e block:block_rq_issue -ag^Cperf report
網(wǎng)絡的監(jiān)測是所有 Linux 子系統(tǒng)里面最復雜的，有太多的因素在里面，比如：延遲、阻塞、沖突、丟包等，更糟的是與 Linux 主機相連的路由器、交換機、無線信號都會影響到整體網(wǎng)絡并且很難判斷是因為 Linux 網(wǎng)絡子系統(tǒng)的問題還是別的設備的問題，增加了監(jiān)測和判斷的復雜度?，F(xiàn)在我們使用的所有網(wǎng)卡都稱為自適應網(wǎng)卡，意思是說能根據(jù)網(wǎng)絡上的不同網(wǎng)絡設備導致的不同網(wǎng)絡速度和工作模式進行自動調整。
//顯示網(wǎng)絡統(tǒng)計信息netstat -s//顯示當前UDP連接狀況netstat -nu//顯示UDP端口號的使用情況netstat -apu//統(tǒng)計機器中網(wǎng)絡連接各個狀態(tài)個數(shù)netstat -a | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'//顯示TCP連接ss -t -a//顯示sockets摘要信息ss -s//顯示所有udp socketsss -u -a//tcp,etcp狀態(tài)sar -n TCP,ETCP 1//查看網(wǎng)絡IOsar -n DEV 1//抓包以包為單位進行輸出tcpdump -i eth2 host 192.168.1.1 and port 80 //抓包以流為單位顯示數(shù)據(jù)內容tcpflow -cp host 192.168.1.1Load 就是對計算機干活多少的度量（WikiPedia：the system Load is a measure of the amount of work that a compute system is doing）簡單的說是進程隊列的長度。Load Average 就是一段時間（1分鐘、5分鐘、15分鐘）內平均Load。
//查看負載情況uptimetopvmstat//統(tǒng)計系統(tǒng)調用耗時情況strace -c -p pid//跟蹤指定的系統(tǒng)操作例如epoll_waitstrace -T -e epoll_wait -p pid//查看內核日志信息dmesg
火焰圖（Flame Graph是 Bredan Gregg 創(chuàng)建的一種性能分析圖表，因為它的樣子近似 ?而得名。
火焰圖主要是用來展示 CPU的調用棧。
y 軸表示調用棧，每一層都是一個函數(shù)。調用棧越深，火焰就越高，頂部就是正在執(zhí)行的函數(shù)，下方都是它的父函數(shù)。
x 軸表示抽樣數(shù)，如果一個函數(shù)在 x 軸占據(jù)的寬度越寬，就表示它被抽到的次數(shù)多，即執(zhí)行的時間長。注意，x 軸不代表時間，而是所有的調用棧合并后，按字母順序排列的。
火焰圖就是看頂層的哪個函數(shù)占據(jù)的寬度最大。只要有”平頂”（plateaus），就表示該函數(shù)可能存在性能問題。顏色沒有特殊含義，因為火焰圖表示的是 CPU 的繁忙程度，所以一般選擇暖色調。
常見的火焰圖類型有On-CPU、Off-CPU、Memory、Hot/Cold、Differential等等。
//安裝systemtap，默認系統(tǒng)已安裝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
git clone https://github.com/lidaohang/quick_location.gitcd quick_location
cpu占用過高，或者使用率提不上來，你能快速定位到代碼的哪塊有問題嗎？
一般的做法可能就是通過日志等方式去確定問題?，F(xiàn)在我們有了火焰圖，能夠非常清晰的發(fā)現(xiàn)哪個函數(shù)占用cpu過高，或者過低導致的問題。
cpu占用過高，執(zhí)行中的時間通常又分為用戶態(tài)時間user和系統(tǒng)態(tài)時間sys。
使用方式：
//on-CPU usersh ngx_on_cpu_u.sh pid//進入結果目錄cd ngx_on_cpu_u//on-CPU kernelsh ngx_on_cpu_k.sh pid//進入結果目錄cd ngx_on_cpu_k//開一個臨時端口8088python -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火焰圖：
cpu過低，利用率不高。等待下一輪CPU，或者等待I/O、鎖、換頁等等，其狀態(tài)可以細分為可執(zhí)行、匿名換頁、睡眠、鎖、空閑等狀態(tài)。
使用方式：
// off-CPU usersh ngx_off_cpu_u.sh pid//進入結果目錄cd ngx_off_cpu_u//off-CPU kernelsh ngx_off_cpu_k.sh pid//進入結果目錄cd ngx_off_cpu_k//開一個臨時端口8088python -m SimpleHTTPServer 8088//打開瀏覽器輸入地址127.0.0.1:8088/pid.svg
官網(wǎng)DEMO：
如果線上程序出現(xiàn)了內存泄漏，并且只在特定的場景才會出現(xiàn)。這個時候我們怎么辦呢？有什么好的方式和工具能快速的發(fā)現(xiàn)代碼的問題呢？同樣內存級別火焰圖幫你快速分析問題的根源。
使用方式：
sh ngx_on_memory.sh pid//進入結果目錄cd ngx_on_memory//開一個臨時端口8088python -m SimpleHTTPServer 8088//打開瀏覽器輸入地址127.0.0.1:8088/pid.svg
官網(wǎng)DEMO：
你能快速定位CPU性能回退的問題么？如果你的工作環(huán)境非常復雜且變化快速，那么使用現(xiàn)有的工具是來定位這類問題是很具有挑戰(zhàn)性的。當你花掉數(shù)周時間把根因找到時，代碼已經(jīng)又變更了好幾輪，新的性能問題又冒了出來。主要可以用到每次構建中，每次上線做對比看，如果損失嚴重可以立馬解決修復。
通過抓取了兩張普通的火焰圖，然后進行對比，并對差異部分進行標色：紅色表示上升，藍色表示下降。差分火焰圖是以當前（“修改后”）的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紅藍差分火焰圖：
通過監(jiān)控插件發(fā)現(xiàn)在2017.09.25 19點nginx集群請求流量出現(xiàn)大量的499，5xx狀態(tài)碼。并且發(fā)現(xiàn)機器cpu使用率升高，目前一直持續(xù)中。
a) **分析nginx請求流量：
結論：
通過上圖發(fā)現(xiàn)流量并沒有突增，反而下降了，跟請求流量突增沒關系。
b) **分析nginx響應時間
結論：
通過上圖發(fā)現(xiàn)nginx的響應時間有增加可能跟nginx自身有關系或者跟后端upstream響應時間有關系。
c) **分析nginx upstream響應時間
結論：
通過上圖發(fā)現(xiàn)nginx upstream 響應時間有增加，目前猜測可能后端upstream響應時間拖住nginx，導致nginx出現(xiàn)請求流量異常。
a) **通過top觀察系統(tǒng)指標
top
結論：
發(fā)現(xiàn)nginx worker cpu比較高
b) **分析nginx進程內部cpu情況
perf top -p pid
結論：
發(fā)現(xiàn)主要開銷在free,malloc,json解析上面
10.4 火焰圖分析cpu
a) **生成用戶態(tài)cpu火焰圖
//on-CPU usersh ngx_on_cpu_u.sh pid//進入結果目錄cd ngx_on_cpu_u//開一個臨時端口8088python -m SimpleHTTPServer 8088//打開瀏覽器輸入地址127.0.0.1:8088/pid.svg
結論：
發(fā)現(xiàn)代碼里面有頻繁的解析json操作，并且發(fā)現(xiàn)這個json庫性能不高，占用cpu挺高。
a) 分析請求流量異常，得出nginx upstream后端機器響應時間拉長
b) 分析nginx進程cpu高，得出nginx內部模塊代碼有耗時的json解析以及內存分配回收操作
根據(jù)以上兩點問題分析的結論，我們進一步深入分析。
后端upstream響應拉長，最多可能影響nginx的處理能力。但是不可能會影響nginx內部模塊占用過多的cpu操作。并且當時占用cpu高的模塊，是在請求的時候才會走的邏輯。不太可能是upstram后端拖住nginx，從而觸發(fā)這個cpu的耗時操作。
遇到這種問題，我們優(yōu)先解決已知的，并且非常明確的問題。那就是cpu高的問題。解決方式先降級關閉占用cpu過高的模塊，然后進行觀察。經(jīng)過降級關閉該模塊cpu降下來了，并且nginx請求流量也正常了。之所以會影響upstream時間拉長，因為upstream后端的服務調用的接口可能是個環(huán)路再次走回到nginx。
以上是“Linux問題故障定位的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業(yè)資訊頻道！
免責聲明：本站發(fā)布的內容（圖片、視頻和文字）以原創(chuàng)、轉載和分享為主，文章觀點不代表本網(wǎng)站立場，如果涉及侵權請聯(lián)系站長郵箱：is@yisu.com進行舉報，并提供相關證據(jù)，一經(jīng)查實，將立刻刪除涉嫌侵權內容。
