掌握運維必備技能--問題故障定位

1. 背景

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

2. 說明

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

3. 分析問題的方法論

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

1. What-現象是什麼樣的

2. When-什麼時候發生

3. Why-為什麼會發生

4. Where-哪個地方發生的問題

5. How much-耗費了多少資源

6. How to do-怎麼解決問題

4. CPU

4.1 說明

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

執行緒的狀態分析主要是分析執行緒的時間用在什麼地方，而執行緒狀態的分類一般分為：

a. on-CPU：執行中，執行中的時間通常又分為使用者態時間user和系統態時間sys。

b. off-CPU：等待下一輪上CPU，或者等待I/O、鎖、換頁等等，其狀態可以細分為可執行、匿名換頁、睡眠、鎖、空閒等狀態。

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

1. 處理器

2. 核

3. 硬體執行緒

4. CPU記憶體快取

5. 時脈頻率

6. 每指令週期數CPI和每週期指令數IPC

7. CPU指令

8. 使用率

9. 使用者時間／核心時間

10. 排程器

11. 執行佇列

12. 搶佔

13. 多程式

14. 多執行緒

15. 字長

4.2 分析工具

說明:

1. uptime,vmstat,mpstat,top,pidstat只能查詢到cpu及負載的的使用情況。

2. perf可以跟著到程式內部具體函式耗時情況，並且可以指定核心函式進行統計，指哪打哪。

4.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

5. 記憶體

5.1 說明

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

1. 主存

2. 虛擬記憶體

3. 常駐記憶體

4. 地址空間

5. OOM

6. 頁快取

7. 缺頁

8. 換頁

9. 交換空間

10. 交換

11. 使用者分配器libc、glibc、libmalloc和mtmalloc

12. LINUX核心級SLUB分配器

5.2 分析工具

說明：

1. free,vmstat,top,pidstat,pmap只能統計記憶體資訊以及程式的記憶體使用情況。

2. valgrind可以分析記憶體洩漏問題。

3. dtrace動態跟蹤。需要對核心函式有很深入的瞭解，透過D語言編寫指令碼完成跟蹤。

5.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  ./程式名

6. 磁碟IO

6.1 說明

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

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

1. 檔案系統

2. VFS

3. 檔案系統快取

4. 頁快取page cache

5. 緩衝區快取記憶體buffer cache

6. 目錄快取

7. inode

8. inode快取

9. noop呼叫策略

6.2 分析工具

6.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

^C

perf report

7. 網路

7.1 說明

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

7.2 分析工具

7.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 sockets

ss -u -a

//tcp,etcp狀態

sar -n TCP,ETCP 1

//檢視網路IO

sar -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 分析工具

8.3 使用方式

//檢視負載情況

uptime

top

vmstat

//統計系統呼叫耗時情況

strace -c -p pid

//跟蹤指定的系統操作例如epoll_wait

strace -T -e epoll_wait -p pid

//檢視核心日誌資訊

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.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

//安裝核心除錯庫

debuginfo-install --enablerepo=debuginfo search kernel

debuginfo-install --enablerepo=debuginfo  search glibc

9.3 安裝

git clone

cd 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：

DEMO火焰圖：

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：

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：

9.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：

DEMO紅藍差分火焰圖：

10. 案例分析

10.1 接入層nginx叢集異常現象

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

10.2 分析nginx相關指標

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

結論：

透過上圖發現流量並沒有突增，反而下降了，跟請求流量突增沒關係。

b) ****分析nginx響應時間

結論：

透過上圖發現nginx的響應時間有增加可能跟nginx自身有關係或者跟後端upstream響應時間有關係。

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

結論：

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

10.3 分析系統cpu情況

a) ****透過top觀察系統指標

top

結論：

發現nginx worker cpu比較高

b) ****分析nginx程式內部cpu情況

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

結論：

發現程式碼裡面有頻繁的解析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. 參考資料

5. http://www.brendangregg.com/blog/2014-11-09/differential-flame-graphs.html

本文作者：李航，多年的底層開發經驗，在高效能nginx開發和分散式快取redis cluster有著豐富的經驗，目前從事分散式儲存Ceph工作。先後在58同城、汽車之家、優酷土豆集團工作。 目前供職於滴滴基礎平臺運維部-技術專家崗位，主要負責分散式Ceph系統。個人主要關注的技術領域：高效能Nginx開發、分散式快取、分散式儲存。

來源：簡書，轉載請聯絡作者獲得授權