Linux問題故障定位大全

1、背景

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

2、說明

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

3、分析問題的方法論

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

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

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

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

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

How much-耗費了多少資源

How to do-怎么解決問題

4、cpu

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

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

處理器

核

硬件線程

CPU內(nèi)存緩存

時鐘頻率

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

CPU指令

使用率

用戶時間／內(nèi)核時間

調(diào)度器

運行隊列

搶占

多進程

多線程

字長

4.2 分析工具

說明：

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

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

4.3 使用方式

5、內(nèi)存

5.1 說明

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

主存

虛擬內(nèi)存

常駐內(nèi)存

地址空間

OOM

頁緩存

缺頁

換頁

交換空間

交換

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

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

5.2 分析工具

說明：

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

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

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

5.3 使用方式

6、磁盤IO

6.1 說明

磁盤通常是計算機最慢的子系統(tǒng)，也是最容易出現(xiàn)性能瓶頸的地方，因為磁盤離 CPU 距離最遠而且 CPU 訪問磁盤要涉及到機械操作，比如轉(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)用策略

6.2 分析工具

6.3 使用方式

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

7.1 說明

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

7.2 分析工具

7.3 使用方式

8、系統(tǒng)負載

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分鐘）內(nèi)平均Load。

8.2 分析工具

8.3 使用方式

9、火焰圖

9.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等等。

9.2 安裝依賴庫

9.3 安裝

9.4 CPU級別火焰圖

cpu占用過高，或者使用率提不上來，你能快速定位到代碼的哪塊有問題嗎？ 一般的做法可能就是通過日志等方式去確定問題?，F(xiàn)在我們有了火焰圖，能夠非常清晰的發(fā)現(xiàn)哪個函數(shù)占用cpu過高，或者過低導致的問題。

9.4.1 on-CPU

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

使用方式：

DEMO：

DEMO火焰圖：

9.4.2 off-CPU

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

使用方式：

官網(wǎng)DEMO：

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

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

使用方式：

官網(wǎng)DEMO：

9.6 性能回退-紅藍差分火焰圖

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

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

使用方式：

DEMO：

DEMO紅藍差分火焰圖：

10、案例分析

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

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

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

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，導致nginx出現(xiàn)請求流量異常。

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

a) **** 通過top觀察系統(tǒng)指標

top

結(jié)論：

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

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

perf top -p pid

結(jié)論：

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

10.4 火焰圖分析cpu

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

結(jié)論：

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

10.5 案例總結(jié)

**a) **分析請求流量異常，得出nginx upstream后端機器響應(yīng)時間拉長

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

10.5.1 深入分析

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

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

10.5.2 解決方式

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





審核編輯：劉清