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