Linux 問題故障定位，看這一篇就夠了
一、 背景
有時候會遇到一些疑難雜症，而且監控插件並不能一眼立馬發現問題的根源。這時候就須要登陸服務器進一步深刻分析問題的根源。那麼分析問題須要有必定的技術經驗積累，而且有些問題涉及到的領域很是廣，才能定位到問題。因此，分析問題和踩坑是很是鍛鍊一我的的成長和提高自我能力。若是咱們有一套好的分析工具，那將是事半功倍，可以幫助你們快速定位問題，節省你們不少時間作更深刻的事情。html
說明
本篇文章主要介紹各類問題定位的工具以及會結合案例分析問題。node
做者：Lucien_168
連接： https://www.jianshu.com/p/0bb...
二、 分析問題的方法論
套用5W2H方法，能夠提出性能分析的幾個問題python
- What-現象是什麼樣的
- When-何時發生
- Why-爲何會發生
- Where-哪一個地方發生的問題
- How much-耗費了多少資源
- How to do-怎麼解決問題
三、cpu
3.1 說明ios
針對應用程序，咱們一般關注的是內核CPU調度器功能和性能。nginx
線程的狀態分析主要是分析線程的時間用在什麼地方，而線程狀態的分類通常分爲：git
a. on-CPU：執行中，執行中的時間一般又分爲用戶態時間user和系統態時間sys。
b. off-CPU：等待下一輪上CPU，或者等待I/O、鎖、換頁等等，其狀態能夠細分爲可執行、匿名換頁、睡眠、鎖、空閒等狀態。github
若是大量時間花在CPU上，對CPU的剖析可以迅速解釋緣由；若是系統時間大量處於off-cpu狀態，定位問題就會費時不少。可是仍然須要清楚一些概念：json
- 處理器
- 核
- 硬件線程
- CPU內存緩存
- 時鐘頻率
- 每指令週期數CPI和每週期指令數IPC
- CPU指令
- 使用率
- 用戶時間／內核時間
- 調度器
- 運行隊列
- 搶佔
- 多進程
- 多線程
- 字長
3.2 分析工具後端
說明:瀏覽器
- uptime,vmstat,mpstat,top,pidstat只能查詢到cpu及負載的的使用狀況。
- perf能夠跟着到進程內部具體函數耗時狀況，而且能夠指定內核函數進行統計，指哪打哪。
3.3 使用方式
//查看系統cpu使用狀況 top //查看全部cpu核信息 mpstat -P ALL 1 //查看cpu使用狀況以及平均負載 vmstat 1 //進程cpu的統計信息 pidstat -u 1 -p pid //跟蹤進程內部函數級cpu使用狀況 perf top -p pid -e cpu-clock
四、內存
4.1 說明
內存是爲提升效率而生，實際分析問題的時候，內存出現問題可能不僅是影響性能，而是影響服務或者引發其餘問題。一樣對於內存有些概念須要清楚：
- 主存
- 虛擬內存
- 常駐內存
- 地址空間
- OOM
- 頁緩存
- 缺頁
- 換頁
- 交換空間
- 交換
- 用戶分配器libc、glibc、libmalloc和mtmalloc
- LINUX內核級SLUB分配器
4.2 分析工具
說明：
- free,vmstat,top,pidstat,pmap只能統計內存信息以及進程的內存使用狀況。
- valgrind能夠分析內存泄漏問題。
- dtrace動態跟蹤。須要對內核函數有很深刻的瞭解，經過D語言編寫腳本完成跟蹤。
4.3 使用方式
//查看系統內存使用狀況 free -m //虛擬內存統計信息 vmstat 1 //查看系統內存狀況 top //1s採集週期，獲取內存的統計信息 pidstat -p pid -r 1 //查看進程的內存映像信息 pmap -d pid //檢測程序內存問題 valgrind --tool=memcheck --leak-check=full --log-file=./log.txt ./程序名
五、 磁盤IO
5.1 說明
磁盤一般是計算機最慢的子系統，也是最容易出現性能瓶頸的地方，由於磁盤離 CPU 距離最遠並且 CPU 訪問磁盤要涉及到機械操做，好比轉軸、尋軌等。訪問硬盤和訪問內存之間的速度差異是以數量級來計算的，就像1天和1分鐘的差異同樣。要監測 IO 性能，有必要了解一下基本原理和 Linux 是如何處理硬盤和內存之間的 IO 的。
在理解磁盤IO以前，一樣咱們須要理解一些概念，例如：
- 文件系統
- VFS
- 文件系統緩存
- 頁緩存page cache
- 緩衝區高速緩存buffer cache
- 目錄緩存
- inode
- inode緩存
- noop調用策略
5.2 分析工具
5.3 使用方式
//查看系統io信息 iotop //統計io詳細信息 iostat -d -x -k 1 10 //查看進程級io的信息 pidstat -d 1 -p pid //查看系統IO的請求，好比能夠在發現系統IO異常時，可使用該命令進行調查，就能指定究竟是什麼緣由致使的IO異常 perf record -e block:block_rq_issue -ag^Cperf report
六、網絡
6.1 說明
網絡的監測是全部 Linux 子系統裏面最複雜的，有太多的因素在裏面，好比：延遲、阻塞、衝突、丟包等，更糟的是與 Linux 主機相連的路由器、交換機、無線信號都會影響到總體網絡而且很難判斷是由於 Linux 網絡子系統的問題仍是別的設備的問題，增長了監測和判斷的複雜度。如今咱們使用的全部網卡都稱爲自適應網卡，意思是說能根據網絡上的不一樣網絡設備致使的不一樣網絡速度和工做模式進行自動調整。
6.2 分析工具
6.3 使用方式
//顯示網絡統計信息
netstat -s
//顯示當前UDP鏈接情況
netstat -nu
//顯示UDP端口號的使用狀況
netstat -apu
//統計機器中網絡鏈接各個狀態個數
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狀態
sar -n TCP,ETCP 1
//查看網絡
IOsar -n DEV 1
//抓包以包爲單位進行輸出
tcpdump -i eth1 host 192.168.1.1 and port 80
//抓包以流爲單位顯示數據內容
tcpflow -cp host 192.168.1.1
七、系統負載
7.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。
7.2 分析工具
7.3 使用方式
//查看負載狀況 uptimetopvmstat //統計系統調用耗時狀況 strace -c -p pid //跟蹤指定的系統操做例如 epoll_waitstrace -T -e epoll_wait -p pid //查看內核日誌信息 dmesg
八、 火焰圖
8.1 說明
火焰圖（Flame Graph是 Bredan Gregg 建立的一種性能分析圖表，由於它的樣子近似 ?而得名。
火焰圖主要是用來展現 CPU的調用棧。
y 軸表示調用棧，每一層都是一個函數。調用棧越深，火焰就越高，頂部就是正在執行的函數，下方都是它的父函數。
x 軸表示抽樣數，若是一個函數在 x 軸佔據的寬度越寬，就表示它被抽到的次數多，即執行的時間長。注意，x 軸不表明時間，而是全部的調用棧合併後，按字母順序排列的。
火焰圖就是看頂層的哪一個函數佔據的寬度最大。只要有」平頂」（plateaus），就表示該函數可能存在性能問題。顏色沒有特殊含義，由於火焰圖表示的是 CPU 的繁忙程度，因此通常選擇暖色調。
常見的火焰圖類型有On-CPU、Off-CPU、Memory、Hot/Cold、Differential等等。
8.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
8.3 安裝
git clone https://github.com/lidaohang/quick_location.gitcd quick_location
8.4 CPU級別火焰圖
cpu佔用太高，或者使用率提不上來，你能快速定位到代碼的哪塊有問題嗎？
通常的作法可能就是經過日誌等方式去肯定問題。如今咱們有了火焰圖，可以很是清晰的發現哪一個函數佔用cpu太高，或者太低致使的問題。
8.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火焰圖：
8.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：
8.5 內存級別火焰圖
若是線上程序出現了內存泄漏，而且只在特定的場景纔會出現。這個時候咱們怎麼辦呢？有什麼好的方式和工具能快速的發現代碼的問題呢？一樣內存級別火焰圖幫你快速分析問題的根源。
使用方式：
sh ngx_on_memory.sh pid //進入結果目錄 cd ngx_on_memory //開一個臨時端口8088 python -m SimpleHTTPServer 8088 //打開瀏覽器輸入地址 127.0.0.1:8088/pid.svg
官網DEMO：
8.6 性能回退-紅藍差分火焰圖
你能快速定位CPU性能回退的問題麼？ 若是你的工做環境很是複雜且變化快速，那麼使用現有的工具是來定位這類問題是很具備挑戰性的。當你花掉數週時間把根因找到時，代碼已經又變動了好幾輪，新的性能問題又冒了出來。主要能夠用到每次構建中，每次上線作對比看，若是損失嚴重能夠立馬解決修復。
經過抓取了兩張普通的火焰圖，而後進行對比，並對差別部分進行標色：紅色表示上升，藍色表示降低。 差分火焰圖是以當前（「修改後」）的profile文件做爲基準，形狀和大小都保持不變。所以你經過色彩的差別就可以很直觀的找到差別部分，且能夠看出爲何會有這樣的差別。
使用方式：
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紅藍差分火焰圖：
九、.案例分析
9.1 接入層nginx集羣異常現象
經過監控插件發如今2017.09.25 19點nginx集羣請求流量出現大量的499，5xx狀態碼。而且發現機器cpu使用率升高，目前一直持續中。
9.2 分析nginx相關指標
a) _**_分析nginx請求流量：
結論：
經過上圖發現流量並無突增，反而降低了，跟請求流量突增不要緊。
b) _**_分析nginx響應時間 
結論：
經過上圖發現nginx的響應時間有增長可能跟nginx自身有關係或者跟後端upstream響應時間有關係。
c) _**_分析nginx upstream響應時間
結論：
經過上圖發現nginx upstream 響應時間有增長，目前猜想可能後端upstream響應時間拖住nginx，致使nginx出現請求流量異常。
9.3 分析系統cpu狀況
a) _**_經過top觀察系統指標
top
結論：
發現nginx worker cpu比較高
b) _**_分析nginx進程內部cpu狀況
perf top -p pid
結論：
發現主要開銷在free,malloc,json解析上面
9.4 火焰圖分析cpu
a) _**_生成用戶態cpu火焰圖
//on-CPU user sh ngx_on_cpu_u.sh pid //進入結果目錄 d ngx_on_cpu_u //開一個臨時端口8088 python -m SimpleHTTPServer 8088 //打開瀏覽器輸入地址 127.0.0.1:8088/pid.svg
結論：
發現代碼裏面有頻繁的解析json操做，而且發現這個json庫性能不高，佔用cpu挺高。
9.5 案例總結
a) 分析請求流量異常，得出nginx upstream後端機器響應時間拉長
b) 分析nginx進程cpu高，得出nginx內部模塊代碼有耗時的json解析以及內存分配回收操做
9.5.1 深刻分析
根據以上兩點問題分析的結論，咱們進一步深刻分析。
後端upstream響應拉長，最多可能影響nginx的處理能力。可是不可能會影響nginx內部模塊佔用過多的cpu操做。而且當時佔用cpu高的模塊，是在請求的時候纔會走的邏輯。不太多是upstram後端拖住nginx，從而觸發這個cpu的耗時操做。
9.5.2 解決方式
遇到這種問題，咱們優先解決已知的，而且很是明確的問題。那就是cpu高的問題。解決方式先降級關閉佔用cpu太高的模塊，而後進行觀察。通過降級關閉該模塊cpu降下來了，而且nginx請求流量也正常了。之因此會影響upstream時間拉長，由於upstream後端的服務調用的接口多是個環路再次走回到nginx。
十、參考資料
- 1. Linux 問題故障定位，看這一篇就夠了
- 2. Linux問題故障定位
- 3. 搞定SEO，看這一篇就夠了
- 4. 排查 Linux 系統故障，看這一篇足夠了。
- 5. nginx看這篇就夠了
- 6. 瞭解 MongoDB 看這一篇就夠了
- 7. RunLoop看這篇就夠了
- 8. mongoDB看這篇就夠了
- 9. npm，看這篇就夠了
- 10. Lombok 看這篇就夠了
- 更多相關文章...
- • Markdown 標題 - Markdown 教程
- • jQuery Mobile 主題 - jQuery Mobile 教程
- • 再有人問你分佈式事務，把這篇扔給他
- • PHP Ajax 跨域問題最佳解決方案
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. Linux 問題故障定位，看這一篇就夠了
- 2. Linux問題故障定位
- 3. 搞定SEO，看這一篇就夠了
- 4. 排查 Linux 系統故障，看這一篇足夠了。
- 5. nginx看這篇就夠了
- 6. 瞭解 MongoDB 看這一篇就夠了
- 7. RunLoop看這篇就夠了
- 8. mongoDB看這篇就夠了
- 9. npm，看這篇就夠了
- 10. Lombok 看這篇就夠了