Linux資源分析工具雜談(長文慎入)

Linux資源分析工具雜談

 

       開篇以前請你們先思考一個問題：

 

       磁盤的平均I/O響應時間是1 ms，這個指標是好，仍是差？

 

       衆所周知，計算機科學是客觀的，也就是說對於一個給定的問題，咱們老是能給出明確的答案，好比咱們網上購物買了兩件100元的衣服，咱們應該付款200元，可是系統給咱們計算出的金額確是300元，咱們能夠明確的告訴商家，結果算錯了。與此不一樣，性能卻經常是主觀的，甚至對性能問題的判斷均可能是不許確的，好比咱們剛剛提到的1ms，必定有人認爲是好的，也有人認爲是差的，要客觀的回答這個問題，多是一項系統性的工做，必須須要首先定義基準（基準定義自己相對複雜，內容能夠寫一本書，在此不作深刻討論），有了基準指標，經過比較才能得出合理的結論。表1列出了一些數值，指望可使你們對計算機科學的一些延時有一個粗略的概念，表中以一個3.3GHZ主頻的CPU一次訪問寄存器爲基準進行說明，好比若是咱們認爲計算機世界中一次寄存器訪問的時間0.3納秒是現實生活中的1秒，那麼訪問一次內存的相對時間就是6分鐘，表1中參考數據源自互聯網。

 

 

表1. 計算機科學中的延時

 

       軟件發展到今天可謂突飛猛進，短短的幾十年中極大的提升了人類的生產力。伴隨着軟件功能的發展，軟件的複雜度也在幾何級的增加，從經濟性的角度來說，人們老是但願投入更少的硬件資源，更少的電力，更少的時間來完成更多的生產任務，人們指望本身的每一度電，每一分鐘時間都在用在有意義的生產活動中。面對複雜的軟件，咱們如何知道軟件在作有意義的事情而不是在無心義的阻塞，或者系統的哪一部分確實存在性能瓶頸，好比內存過小，硬盤太慢，CPU太慢等等。系統性能分析能夠在不一樣的維度進行審視，經常使用的維度有負載分析和資源分析，本文但願從資源分析的角度對相關的工具進行討論。

       中國有句古話，工欲善其事，必先利其器，人類文明進步的最重要的標誌就是能夠在對的時候使用對的工具。可是問題來了，什麼是對的時候使用對的工具？前人對問題總結後分紅了三類，第一種是理解問題，也知道如何解決問題，第二種是理解問題，可是以我的的能力沒法解決問題，第三類問題是不知道問題的存在，更不知道如何解決問題。第一種問題和第二種問題咱們稱之爲基礎問題，由於咱們能夠經過我的能力或者團隊合做解決這類問題，第三種問題未知的未知纔是咱們須要重點關注的問題，理論上來講，在一個成熟的軟件開發週期中，不容許存在未知的未知，咱們須要對系統的各個層次都有透徹的理解和深刻的把握。

       當今世界的三大主流操做系統Linux, Windows NT, Mac OS都提供了系統的工具集來監控，排查各種性能問題，好比Windows平臺上Mark Russinovich的Sysinternals工具集，Windbg工具集，Linux 平臺上的Sysstat工具集, Brendan Gregg力推的DTrace工具集。爲了解決已知和未知的問題，咱們首先須要對操做系統和硬件的相關指標有一個基礎的認識，不然即便有了適合的工具，統計出了詳盡的結果，咱們仍然沒法透徹的理解軟件和系統發生了什麼。如圖1所示是性能分析大神Brendan Gregg對經常使用的性能分析工具進行的詳盡總結。

 

 

 

圖1. Linux Performance Tools

 

基礎篇

 

       下面咱們對圖1中的一些經常使用基礎分析工具以及應用場景進行簡單的分析。經常使用的性能分析工具包括：uptime, vmstat, mpstat, sar, ps, top, pidstat等等，這些命令的簡單描述請見表2。

 

 

表2. 經常使用性能分析工具簡單描述

 

       系統發生CPU性能問題時一般第一個使用的命令是uptime和top，uptime命令輸出系統過去1分鐘，5分鐘和15分鐘的平均負載，經過這三個數值能夠粗略的分析出系統過去15分鐘內負載是下降了，升高了，或者是持平，uptime運行結果如圖2所示。

 

 

圖2. uptime運行結果

 

       多核系統分析中接下來要使用的命令一般是mpstat，咱們能夠經過mpstat對CPU的每一個核的使用狀況都進行監控，mpstat不只能夠對每一個核心的數據進行分別統計，還能夠對全部核心的平均使用狀況進行統計，mpstat運行結果如圖3所示。

 

 

圖3. mpstat運行結果

 

       當咱們使用top發現某一個進程的CPU或者其餘資源使用異常的時候，咱們可能須要引入第三個命令pidstat，咱們甚至能夠將這一統計數據精確到具體的線程。Top和pidstat運行結果見圖4和圖5。

 

圖4. Top運行結果

 

 

圖5. Pidstat分線程運行結果

 

       當咱們須要對tcp流量進行簡單統計，又不肯意要引入更復雜的tcpdump網絡監控的時候，sar命令是個不錯的選擇，固然，統計網絡流量只是sar的一個功能而已，更多功能能夠參考sar man page， 使用sar命令統計tcp流量運行結果如圖6所示。

 

圖6. sar命令統計tcp流量運行結果

 

       限於篇幅的緣由，此處再也不一一討論圖1中的每個命令。

 

進階篇

       動態追蹤是一種高級調試技術能夠幫助開發人員以很是低的成本快速排查和解決軟件性能問題。當今世界軟件面臨的問題一是規模，二是複雜度。隨着 BPF 追蹤系統（基於時間採樣）最後一個主要功能被合併至 Linux 4.9-rc1 版本的內核中，Linux內核擁有了相似DTrace的原生追蹤功能。DTrace是Solaris系統中的高級追蹤器，功能強大，對於長期使用 DTrace 的用戶，這是一個振奮人心的消息，如今Linux系統上能夠在生產環境中使用安全的、低負載的定製追蹤系統，經過執行時間的柱狀圖和頻率統計等信息，分析應用的性能以及內核。最初用於Linux的追蹤項目有不少，可是這個最終被合併進Linux內核的技術從一開始就根本不是一個追蹤項目：它最開始是用於伯克利包過濾器 Berkeley Packet Filter（BPF）的一個加強功能。這些補丁容許BPF重定向數據包，從而建立軟件定義網絡。長此以往，對事件追蹤的支持就被添加進來了，使得程序追蹤可用於Linux系統。BPF Compiler Collection (BCC), PLY 和 BPFTRACE都是正在開發的BPF前端，BCC架構如圖7所示，下面以BCC爲例對Linux動態追蹤技術進行簡單說明，

 

 

圖7. Linux BCC/BPF Tracing Tools

 

       假設咱們有這樣一個場景，系統中偶爾會運行新的進程，這些新的進程可能會消耗大量系統資源，從而對咱們生產上運行的環境產生干擾，可是這種進程可能運行時間極爲短暫，咱們怎樣才能知道發生了這種狀況呢？top？可能不行，時間過短了，可能top還沒來得及統計，進程已經退出了。這種狀況下最適合使用的工具之一就是BCC工具集中的execsnoop，圖8中能夠看出，每個新啓動的進程都會被記錄在案。

 

圖8. Execsnoop命令運行結果

 

       網絡程序開發中咱們可能想要按照TCP鏈接來統計一下通訊兩端的吞吐量和生命週期，這個時候tcplife就派上用場了，tcplife對TCP會話的生命週期和吞吐量統計如圖9所示。

 

 

圖9. Tcplife命令運行結果

 

       對於一個給定的進程，咱們甚至能夠要求內核經過BPF統計CPU處理以外時間的內核和用戶堆棧，具體使用方法和示例請見圖10。

 

圖10 offcputime命令運行結果

 

總結

       本文對Linux資源分析相關的基礎工具、高級工具以及典型應用場景進行了簡單的總結，算是拋磚引玉，但願對你們有所幫助。