Linux問題故障定位的知識點有哪些

這篇文章主要講解了“Linux問題故障定位的知識點有哪些”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“Linux問題故障定位的知識點有哪些”吧！

創(chuàng)新互聯(lián)公司長期為上千余家客戶提供的網(wǎng)站建設(shè)服務(wù)，團(tuán)隊從業(yè)經(jīng)驗10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為柳南企業(yè)提供專業(yè)的網(wǎng)站設(shè)計制作、成都網(wǎng)站建設(shè)，柳南網(wǎng)站改版等技術(shù)服務(wù)。擁有十載豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。

分析問題的方法論

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

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

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

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

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

• How much-耗費了多少資源

• How to do-怎么解決問題

CPU

1 說明

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

線程的狀態(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)可以細(xì)分為可執(zhí)行、匿名換頁、睡眠、鎖、空閑等狀態(tài)。

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

• 處理器

• 核

• 硬件線程

• CPU內(nèi)存緩存

• 時鐘頻率

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

• CPU指令

• 使用率

• 用戶時間/內(nèi)核時間

• 調(diào)度器

• 運行隊列

• 搶占

• 多進(jìn)程

• 多線程

• 字長

2 分析工具

說明:

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

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

3 使用方式

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

內(nèi)存

1 說明

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

• 主存

• 虛擬內(nèi)存

• 常駐內(nèi)存

• 地址空間

• OOM

• 頁緩存

• 缺頁

• 換頁

• 交換空間

• 交換

• 用戶分配器libc、glibc、libmalloc和mtmalloc

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

2 分析工具

說明：

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

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

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

3 使用方式

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

 磁盤IO

1 說明

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

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

• 文件系統(tǒng)

• VFS

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

• 頁緩存page cache

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

• 目錄緩存

• inode

• inode緩存

• noop調(diào)用策略

2 分析工具

3 使用方式

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

網(wǎng)絡(luò)

1 說明

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

2 分析工具

3 使用方式

//顯示網(wǎng)絡(luò)統(tǒng)計信息 netstat -s  //顯示當(dāng)前UDP連接狀況 netstat -nu  //顯示UDP端口號的使用情況 netstat -apu  //統(tǒng)計機(jī)器中網(wǎng)絡(luò)連接各個狀態(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 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

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

1 說明

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

2 分析工具

3 使用方式

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

火焰圖

1 說明

火焰圖(Flame Graph是 Bredan Gregg 創(chuàng)建的一種性能分析圖表，因為它的樣子近似 ?而得名。

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

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

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

火焰圖就是看頂層的哪個函數(shù)占據(jù)的寬度***。只要有”平頂”(plateaus)，就表示該函數(shù)可能存在性能問題。顏色沒有特殊含義，因為火焰圖表示的是 CPU  的繁忙程度，所以一般選擇暖色調(diào)。

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

2 安裝依賴庫

//安裝systemtap，默認(rèn)系統(tǒng)已安裝 yum install systemtap systemtap-runtime  //內(nèi)核調(diào)試庫必須跟內(nèi)核版本對應(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)試庫 debuginfo-install --enablerepo=debuginfo search kernel debuginfo-install --enablerepo=debuginfo  search glibc

3 安裝

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

4 CPU級別火焰圖

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

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

4.1 on-CPU

cpu占用過高，執(zhí)行中的時間通常又分為用戶態(tài)時間user和系統(tǒng)態(tài)時間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  //開一個臨時端口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火焰圖：

4.2 off-CPU

CPU過低，利用率不高。等待下一輪CPU，或者等待I/O、鎖、換頁等等，其狀態(tài)可以細(xì)分為可執(zhí)行、匿名換頁、睡眠、鎖、空閑等狀態(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  //開一個臨時端口8088 python -m SimpleHTTPServer 8088  //打開瀏覽器輸入地址 127.0.0.1:8088/pid.svg

官網(wǎng)DEMO：

5 內(nèi)存級別火焰圖

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

使用方式：

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

官網(wǎng)DEMO：

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

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

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

使用方式：

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 <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紅藍(lán)差分火焰圖：

案例分析

1 接入層nginx集群異?，F(xiàn)象

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

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

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

結(jié)論：

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

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

結(jié)論：

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

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

結(jié)論：

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

3 分析系統(tǒng)CPU情況

a) **通過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)主要開銷在free,malloc,json解析上面

4 火焰圖分析CPU

a) **生成用戶態(tài)CPU火焰圖

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

結(jié)論：

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

感謝各位的閱讀，以上就是“Linux問題故障定位的知識點有哪些”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對Linux問題故障定位的知識點有哪些這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！

網(wǎng)站題目：Linux問題故障定位的知識點有哪些
文章路徑：http://bm7419.com/article42/jjssec.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站內(nèi)鏈、商城網(wǎng)站、企業(yè)建站、響應(yīng)式網(wǎng)站、營銷型網(wǎng)站建設(shè)、域名注冊

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)