Linux下故障分析方法

文 | Lucien_168

1、背景

我們應該如何培養(yǎng)孩子的創(chuàng)造力？

這是個無法給出標準答案的問題。不過，我們可以從歷史中尋求一些借鑒。

十四年前，互聯網巨頭Google就曾做過類似的嘗試。20%時間法則，就是那次“偉大的嘗試”貢獻給世界的禮物。

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

2005年，Google那一年“七歲”，業(yè)務也已走上了正軌。正如投資上不會把雞蛋放在同一個籃子里，當時的Google的管理層也意識到：如果想要長久的、持續(xù)的發(fā)展，把100%的資源與精力全部撲在當前業(yè)務上，未必是最優(yōu)選擇。

優(yōu)秀的公司，都會居安思危；在這方面，互聯網公司有更強烈的危機感。在輕資產型的互聯網公司，技術上能否領先，決定的不是落后與領先，而是生死。

現在還有多少人知道，第一個做商業(yè)搜索引擎的并非是Google。早在Google創(chuàng)立的前四年，就已有了做商業(yè)搜索引擎的公司。如果不是因為搞出了“PageRank”，在算法上更具技術優(yōu)勢，憑什么一個在車庫里走出來的初創(chuàng)小公司，能夠打敗一幫業(yè)界大佬，成為“搜索之王”。

2、說明

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

3、分析問題的方法論

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

• What-現象是什么樣的

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

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

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

• How much-耗費了多少資源

• How to do-怎么解決問題

4、CPU

4.1 說明

針對應用程序，我們通常關注的是內核CPU調度器功能和性能。

線程的狀態(tài)分析主要是分析線程的時間用在什么地方，而線程狀態(tài)的分類一般分為：

a. on-CPU：執(zhí)行中，執(zhí)行中的時間通常又分為用戶態(tài)時間user和系統態(tài)時間sys。

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

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

• 處理器

• 核

• 硬件線程

• CPU內存緩存

• 時鐘頻率

• 每指令周期數CPI和每周期指令數IPC

• CPU指令

• 使用率

• 用戶時間／內核時間

• 調度器

• 運行隊列

• 搶占

• 多進程

• 多線程

• 字長

4.2 分析工具

說明：

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

• perf可以跟著到進程內部具體函數耗時情況，并且可以指定內核函數進行統計，指哪打哪。

4.3 使用方式

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

5、內存

5.1 說明

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

• 主存

• 虛擬內存

• 常駐內存

• 地址空間

• OOM

• 頁緩存

• 缺頁

• 換頁

• 交換空間

• 交換

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

• LINUX內核級SLUB分配器

5.2 分析工具

說明：

• free,vmstat,top,pidstat,pmap只能統計內存信息以及進程的內存使用情況。

• valgrind可以分析內存泄漏問題。

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

5.3 使用方式

6、磁盤IO

6.1 說明

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

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

• 文件系統

• VFS

• 文件系統緩存

• 頁緩存page cache

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

• 目錄緩存

• inode

• inode緩存

• noop調用策略

6.2 分析工具

6.3 使用方式

7、網絡

7.1 說明

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

7.2 分析工具

7.3 使用方式

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 使用方式

9、火焰圖

9.1 說明

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

火焰圖主要是用來展示 CPU的調用棧。

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

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

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

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

9.2 安裝依賴庫

9.3 安裝

9.4 CPU級別火焰圖

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

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

9.4.1 on-CPU

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

使用方式：

DEMO：

DEMO火焰圖：

9.4.2 off-CPU

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

使用方式：

官網DEMO：

9.5 內存級別火焰圖

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

使用方式：

官網DEMO：

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

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

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

使用方式：

DEMO：

DEMO紅藍差分火焰圖：

10、案例分享

10.1 接入層nginx集群異?，F象

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

10.2 分析nginx相關指標

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

結論：

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

b) **分析nginx響應時間

結論：

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

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

結論：

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

10.3 分析系統cpu情況

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

結論：

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

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

結論：

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

10.4 火焰圖分析cpu

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

結論：

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

10.5 案例總結

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

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

10.5.1 深入分析

根據以上兩點問題分析的結論，我們進一步深入分析。

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

10.5.2 解決方式

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

參考資料：

http://www.brendangregg.com/index.html

http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html

http://www.brendangregg.com/FlameGraphs/memoryflamegraphs.html

http://www.brendangregg.com/FlameGraphs/offcpuflamegraphs.html

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

https://github.com/openresty/openresty-systemtap-toolkit

https://github.com/brendangregg/FlameGraph

https://www.slideshare.net/brendangregg/blazing-performance-with-flame-graphs

/ The End /

本文轉載自簡書，作者：Lucien_168

原文鏈接：https://www.jianshu.com/p/0bbac570fa4c