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資源分析相關的基礎工具、高階工具以及典型應用場景進行了簡單的總結，算是拋磚引玉，希望對大家有所幫助。