性能分析、調整方法

 文章內容來自《性能之巔》2.5章節

 昔之善戰者，先爲不可勝，以待敵之可勝。不可勝在己，可勝在敵。

　　　　　　　　　　　　　　　　　　　　---《孫子兵法之軍形篇》

 

1、街燈訛法

　　非深思熟慮的方法。熟悉的觀測工具隨意看看，有概率去命中一些問題，也可能忽視一些問題。

　　性能調整能夠用一種試錯的方式反覆摸索，對所知道的可調參數進行設置，熟悉各類不一樣的值，看看是否有幫助。

　　該方法也能揭示問題，可是當你所熟悉的工具及所作的調整與問題不相關時，進展很緩慢。

　　這個方法用一類觀測誤差來命名，這類誤差叫作街燈效應。出自一篇寓言故事：

　　一天晚上，一個警察看到一個醉漢在路燈下邊的地面找東西，問他在找什麼。醉漢回答說他鑰匙丟了。警察看了看也找不到，就問他：「你肯定你要是是在這兒丟的，就在路燈下？」，醉漢說：「不，可是這兒的光是最亮的」。

　　至關於查看top，不是由於這麼作有道理，而是用戶不知道怎麼樣使用其餘工具。

　　用這個方法找到的問題多是真的問題，但未必是你想要找的那個。

2、隨機變更訛法

　　這是一個實驗性質的訛方法。用戶隨機猜想問題可能存在的位置，而後作改動，直到問題消失。爲了判斷性能是否已經提高，或者做爲每次變更結果的判斷，用戶會選擇一項指標進行研究，諸如應用程序運行時間、延時、操做率（每秒操做數）、或者吞吐量（每秒的字節數）整個方法以下：

　　一、任意選擇一個項目作改動（例如一項可變參數）

　　二、朝某個方向作修改

　　三、測量性能

　　四、朝另外一個方向作修改

　　五、測量性能

　　六、步驟3或者步驟5的結果是否是要好於基準值？若是是，保留修改並返回步驟1

　　這個過程可能最終得到的調整僅適用於被測的工做負載，方法很是耗時並且可能作出的調整不能保持長期有效。例如，一個應用程序的改動規避了一個數據庫或者操做系統的bug，其結果是能夠提高性能，可是當這個bug被修復後，程序這樣的改動就再也不有意義，關鍵是沒有人真正瞭解這件事情。

　　作不瞭解的改動還有另外一個風險，即在生產負載的高峯期可能會引起更惡劣的問題，所以還需爲此準備一套回退方案。

3、責怪他人訛法

　　步驟：
　　一、找到一個不是你負責的系統或環境的組件

　　二、假定問題是與那個組件相關的

　　三、把問題扔給負責那個組件的團隊

　　四、若是證實錯了，返回步驟1

4、Ad Hoc覈對清單法

　　當須要檢查和調試系統時，技術支持人員一般會花一點時間一步步的過一遍覈對清單。一個典型的場景，在產品環境部署新的服務器或應用時，技術支持人員會花半天時間來檢查一遍系統在真實壓力下的常見問題。該類覈對清單是Ad Hoc的，基於該系統類型的經驗和以前所遇到的問題。

　　舉個例子，這是覈對清單中的一項：

　　運行iostat -x 1檢查await列。若是該列在負載下持續超過10ms，那麼說明磁盤太慢或者磁盤過載。

　　一份覈對清單會包含不少這樣的檢查項目。

　　這類清單能在最短的時間內提供最大的價值，是及時建議並且須要頻繁的更新以保證反應當前狀態。這類清單處理的可能是修復方法容易記錄的問題，例如設置可調參數，而不是針對源代碼或者環境作定製的修復。

　　若是你管理一個技術支持的專業團隊，Ad Hoc覈對清單能有效保證全部人都知道如何檢查最糟糕的問題，能覆蓋到全部顯而易見的問題。覈對清單可以寫的清楚並且又規範，說明了如何辨別每個問題和如何作修復。不過固然，這個清單應該時長保持更新。

5、問題陳述法

　　明確問題如何陳述是支持人員開始反映問題時的例行工做，經過詢問客戶一下幾個問題來完成：

　　一、是什麼讓你認爲存在性能問題？

　　二、系統以前運行的好嗎？

　　三、最近有什麼改動？軟件？硬件？負載？

　　四、問題能用延時或者運行時間來表述嗎？

　　五、問題影響其餘的人和應用程序嗎？

　　六、環境是怎麼樣的？用了那些軟件和硬件？是什麼版本？是怎樣的配置？

　　詢問這些問題並獲得相應的回答一般會當即指向一個根源和解決方案。所以問題陳述法做爲獨立的方法收錄於此，並且當你應對一個新的問題時，首先應該使用的就是這個方法。

6、科學法

　　科學法研究未知的問題是經過假設和實驗。步驟：

　　一、問題

　　二、假設

　　三、預測

　　四、實驗

　　五、分析

　　問題就是性能問題的描述。從這點你能夠假設性能不佳的緣由有什麼。而後你進行試驗、能夠是觀測性的也能夠是實驗性的，看看基於假設的預測是否正確。最後是分析收集的試驗數據。

　　舉個例子：你可能發現某個應用程序遷移到一個內存較少的系統時其性能會降低，你假設致使性能很差的緣由是較小的文件系統緩存。你可使用觀測的試驗方法分別測量兩個系統的緩存流失率，預測內存較小的系統緩存流失率會更高。用實驗的方法能夠增長緩存大小（加內存），預測性能將會有所提高。另外，還能夠更簡單，實驗性的測試能夠人爲的減小緩存的小大（利用一些可調參數），預計性能會變差。

　　示例（觀測性）：

　　一、問題：什麼問題致使了數據庫查詢很慢？

　　二、假設：噪聲鄰居（其餘雲計算租戶）在執行磁盤I/0，與數據庫的磁盤I/O在競爭（經過文件系統）

　　三、預測：若是獲得在數據庫查詢過程當中的文件系統I/O延時，能夠看出文件系統對於查詢很慢是有責任的

　　四、試驗：跟蹤文件系統延時，發現文件系統上的等待時間在整個查詢延時中的比例小於5%

　　五、分析：文件系統和磁盤對查詢速度慢沒有責任

　　雖然問題沒有解決，可是環境中的一些大型的組件已經被排除了。執行調查的人能夠回到第2步作一個新的假設。

　　示例（實驗性）：

　　一、問題：爲何HTTP請求從主機A到主機C要比從主機B到主機C的時間長

　　二、假設：主機A和主機B在不一樣的數據中心

　　三、預測：把主機A移動到主機B同樣的數據中心將修復這個問題

　　四、試驗：移動主機A並測試性能

　　五、分析：性能獲得修復--與假設的一致

　　若是問題沒有獲得解決，在開始新的假設以前，要恢復以前試驗的變更！

7、診斷循環

　　診斷週期與科學方法類似：
　　假設-->儀器校驗-->數據-->假設

　　就像科學法同樣，這個方法也是經過收集數據來驗證假設。這個循環強調數據能夠快速的引起新的假設，進而驗證改良，以此繼續。

　　上述兩個方法，理論數據都有很好的平衡。從假設發展到數據的過程很快，那麼很差的理論就可儘早的被識別和遺棄，進而開發更好的理論。

8、工具法

　　導向方法以下：

　　一、列出可用到的性能工具（可選的、安裝的或可購買的）

　　二、對於每個工具，列出它提供的有用的指標

　　三、對於每個指標，列出闡釋該指標可能的規則

　　這個視角的核對清單告訴你那些工具能用、哪些指標能讀，以及怎樣闡釋這些指標。雖然這至關高效，只依賴可用的（或知道的）工具，就能獲得一個不徹底的系統視野，可是與街燈訛法相似，用戶不知道他的視野不完整--並且可能自始至終對此一無所知。須要定製工具（如動態跟蹤）才能發現的問題可能永遠被識別並解決。

　　在實踐中，工具法確實在必定程度上辨別除了資源的瓶頸、錯誤，以及其餘類型的問題，但一般不過高效。

　　當大量的工具和指標可被選用時，逐個枚舉是很耗時的，當多個工具具備相同功能時，狀況更糟，你須要花額外的時間來了解各個工具的優缺點，在某些狀況下，好比要選擇作文件系統微基準的工具的場合，工具至關多，雖然這時候你只須要一個。

9、use方法

　　use方法應用於性能研究，用來識別系統瓶頸一言蔽之就是：

　　對於全部的資源、查看他的使用率、飽和度和錯誤。

　　術語定義：

　　資源：全部服務器物理器件（CPU、總線~~~）某些軟件資源也能算在內，提供有用的指標

　　使用率：在規定的時間間隔內，資源用於服務工做的時間百分比。雖然資源繁忙，可是資源還有能力接受更多的工做，不能接受更多工做的程度被視爲飽和度。

　　錯誤：錯誤事件的個數

　　某些資源類型，包括內存，使用率指的是資源所用的容量。這與基於時間的定義是不一樣的，一旦資源的容量達到100%的使用率，就沒法接受更多的工做，資源或者會把工做進行排隊（飽和），或者返回錯誤，用use方法也就予以鑑別。

　　錯誤須要調查，由於他們會損害性能，若是故障模式是可恢復的，錯誤可能難以當即察覺。這包括操做失敗重試，還有冗餘設備池中的設備故障。

　　與工具法相反的是，use方法列舉的是系統資源而不是工具，這幫助你獲得一張完整的問題列表，在你尋找工具的時候作確認。即使對於有些問題現有的工具沒有答案，但這些問題蘊含的知識對於性能分析也是極其有用的：這些是「已知的已知」

　　use方法會將分析引導到必定數量的關鍵指標上，這樣能夠儘快的核實全部的系統資源。在此以後，若是尚未找到問題，那麼能夠考慮採用其餘的方法。

　　圖描繪了use方法的流程圖。錯誤被置於檢查首位，要先於使用率和飽和度。錯誤一般容易很快被解釋，在研究其餘指標以前，把它們梳理清楚是省時高效的：

　　

 

　　這個方法辨別出的極可能是系統瓶頸的問題，不過，一個系統可能不止面臨一個性能問題，所以你可能一開始就能找到問題，但所找到的問題絕非你關心的那個。在根據須要返回use方法遍歷其餘資源以前，每一個發現能夠用更多的方法進行調查。

　　指標描述：

　　use方法的指標一般以下：

　　使用率：必定時間間隔內的百分比值

　　飽和度：等待隊列的長度

　　錯誤：報告出的錯誤次數

　　雖然看起來有點違反直覺，但即使總體的使用率在很長一段時間都處於較低水平，一次高使用率的瞬時衝擊仍是能致使飽和度與性能問題的。某些監控工具彙報的使用率是超過5分鐘的均值，舉個例子：每秒CPU使用率可能變更的很是劇烈，所以5分鐘的時長的均值可能會掩蓋短期內的100%的使用率，甚至是飽和的狀況。

　　想一想一些高速公路收費站，使用率就至關於有多少收費站在忙於收費。使用率100%意味着你找不到一個空的收費站，必須排在別人的後邊（飽和的狀況）若是我說一成天收費站的使用率是40%，你能判斷當天是否有車在某一時間排過隊嗎？極可能在高峯時候確實排過隊，那時的使用率是100%，可是在這一天的均值上是看不出的。

　　資源列表：

　　use方法的第一步是要建一張資源列表，要儘量完整。下面是一張服務器一般的資源表，配有相應的例子：

　　cpu：插槽、核、硬件線程（虛擬cpu）

　　內存：dram；

　　網絡接口：以太網端口

　　存儲設備：磁盤

　　控制器：存儲、網絡

　　互聯：cpu、內存、I/O

　　每一個組件一般做爲一類資源類型。例如，內存是一種容量資源，網絡接口是一類I/O資源（IOPS或吞吐量）。有些組件體現出多種資源類型：例如，存儲設備既是I/O資源也是容量資源，這時須要考慮到全部的類型都能形成性能瓶頸，同時，也要知道I/O資源可能進一步被當作排隊系統來研究，將請求排隊並被服務。

　　某些物理資源，諸如硬件緩存（如cpu緩存，可能不在清單中。）use方法是處理在高使用率或飽和狀態下性能降低的資源最有效的方法，固然還有其餘的檢測方法。若是你不肯定清單是否該包括一項資源，那就包括它，看看在實際指標中是什麼樣的狀況。

 

　　原理框圖

　　另外一種遍歷全部資源的方法是找到或者畫一張系統的原理框圖，正以下圖示，這樣的圖還顯示了組件的關係，這對尋找數據流動中的瓶頸是頗有幫助的。

　　CPU、內存、I/O互聯和總線經常被忽視。所幸的是，他們不是系統的常見瓶頸，由於這些組件自己就設計有超過吞吐量的餘量。可能你須要升級主板，或者減少負載。例如：零拷貝就減輕了內存和總線的負載

　　

　　指標

　　一旦你掌控了資源的列表，就能夠考慮這三類指標：使用率、飽和度以及錯誤。下表種列舉了一些資源和指標類型，以及一些可能的指標。

　　這些指標要麼是必定時間間隔的均值，要麼是累計數目。

　　

 

　　　　　　　　　　　　雙CPU系統原理框圖示例

　　

　　

　　　　　　　　　　　use方法指標示例

　　重複全部的組合，包括獲取每一個指標的步驟，記錄下當前沒法得到的指標，那些是已知的未知。最終你獲得一個大約30項的指標清單，有些指標難以測量，有些根本測不了。所幸的是常見的問題用較簡單的指標就能發現（例如：CPU飽和度，內存容量飽和度，網絡接口使用率，磁盤使用率），因此這些指標首先要測量

　　一些比較難的組合示例可見下表

　　

 

　　　　　　　　　　　　use方法指標的進階示例

　　上述的某些指標可能用操做系統的標準工具是沒法得到的，可能須要使用動態跟蹤或者用到CPU性能計數器。

　　軟件資源

　　某些軟件資源的檢測方法可能類似。這裏指的是軟件組件，而不是整個應用程序，示例以下：

　　一、互斥鎖：鎖被持有的時間是使用時間，飽和度指的是有線程排隊在等鎖

　　二、線程池：線程忙於處理工做的時間是使用時間，飽和度指的是等待線程池服務的請求數目

　　三、進程/線程容量：系統的進程或線程的總數是有上限的，當前的使用數目是使用率，等待分配認爲是飽和度，錯誤是分配失敗

　　四、文件描述符容量：同進程/線程容量同樣，只不過針對的是文件描述符

　　若是這些指標在你的案例裏管用，就用它們；不然，用其餘方法也是能夠的，如延時分析。

　　使用建議：

　　對於使用上述這些指標類型，這裏有一些整體的建議：

　　使用率：100%的使用率一般是瓶頸的信號（檢查飽和度並確認其影響）。使用率超過60%可能會是問題。基於如下理由：時間間隔的均值，可能掩蓋了100%使用率的短時間爆發，另外，一些資源，諸如硬盤，一般在操做期間是不能被中斷的，即便是作優先級較高的工做，隨着使用率的上升，排隊延時會變的更頻繁和明顯。

　　飽和度：任何程度的飽和都是問題（非零），飽和度能夠用排隊長度或者排隊所花的時間來度量

　　錯誤：錯誤都是值得研究的。尤爲是隨着錯誤增長性能會變差的那些錯誤

　　低使用率、無飽和、無錯誤：這樣的反例研究起來容易。這點要比看起來還有用--縮小研究的範圍能幫你快速的將精力集中在出問題的地方，判斷其不是某一個資源的問題，這是一個排除法的過程。

　　雲計算

　　在雲計算環境，軟件資源控制在於限制或者給分享系統的多個租戶設定閾值。在Joyent的公司，咱們主要用os虛擬技術，來設定內存限制，cpu限制，以及存儲I/O的門限制。每一項資源的限定都能用use方法來檢驗，與檢查物理資源的方法相似。

　　舉個例子，內存容量使用率是租戶的內存使用率與其餘內存容量的比值。內存容量飽和出現於匿名的分頁活動，雖然傳統的頁面掃描此時多是空閒的。

10、工做負載特徵概括

　　工做負載特徵概括是辨別這樣一類問題簡單而又高效的方法--由施加的負載致使的問題。這個問題關注於系統的輸入，而不是所產生的性能。你的系統可能沒有任何架構或者配置上的問題，可是系統的負載超出了它所能承受的合理範圍。

　　工資負載能夠經過回答下列問題來進行特徵概括：

　　一、負載是誰產生的？進行ID，用戶ID，遠端IP地址？

　　二、負載爲何會調用？代碼路徑、堆棧跟蹤？

　　三、負載的特徵是什麼？IOPS、吞吐量、方向類型（讀取/寫入）？包含變更（標準方差），若是有的話

　　四、負載是怎樣隨着時間變化的？有平常模式嗎？

　　將上述全部的問題都作檢查會頗有用，即使你對於答案會是什麼已經有了很強的指望，但仍是應作一遍，由於你可能大吃一驚。

　　請思考這麼一個場景：你碰到一個數據庫性能問題，數據庫請求來自一個web服務器池，你是否是應該檢查正在使用數據庫的IP地址？你本認爲這些應該都是web服務器，正如所配置的那樣。但你檢查後發現好像整個因特網都在往數據庫扔負載，以摧毀其性能。你正處於dos攻擊中！
　　最好的性能來自消滅沒必要要的工做，有時候沒必要要的工做室因爲應用程序的不正常運行引發的，例如：一個困在循環的線程無故的增長CPU的負擔。沒必要要的工做也有可能源於錯誤的配置--舉個例子，在白天運行全系統的備份--或者是以前說過的dos攻擊。概括工做負載的特徵能識別這類問題，經過維護和從新配置能夠解決這些問題。

　　若是被識別出的問題沒法解決，那麼能夠用系統資源控制來限制它。舉個例子，一個系統備份的任務壓縮備份數據會消耗CPU資源，這會影響數據庫，並且還要用網絡資源來傳輸數據。用資源控制來限定備份任務對CPU和網絡的使用（若是系統支持的話）這樣雖然備份仍是會發生，但不影響數據庫

　　除了識別問題，工做負載特徵概括還能夠做爲輸入用於仿真基準設計。若是度量工做負載只是用的均值，理想狀況，你還要收集分佈和變化的細節信息。這對於仿真工做負載的多樣性，而不是僅測試均值負載是很重要的。

　　工做負載分析經過辨識出負載問題，有利於將負載問題和架構問題區分開。

　　執行工做負載特徵概括所用的工具和指標視目標而定。一部分應用程序所記錄的詳細的客戶活動信息能夠成爲統計分析的數據來源。這些程序還能夠提供每日或每個月的用戶試用報告，這也是值得關注的。

11、向下挖掘分析法

　　深度分析開始於在高級別檢查問題，而後依據以前的發現縮小關注的範圍，忽視那些無關的部分，更深刻發掘那些相關的部分。整個過程會探究到軟件棧較深的級別，若是須要，甚至能夠達到硬件層，以求找到問題的根源。

　　在《Solaris性能與工具》一書中，針對系統性能，深度分析方法分爲如下三個階段：

　　一、檢測：用於持續記錄高層級的統計數據，若是問題出現，予以辨別和報警

　　二、識別：對於給定問題，縮小研究的範圍，找到可能的瓶頸

　　三、分析：對特定的系統作進一步的檢查，找到問題根源並量化問題

　　檢測是在公司範圍內執行，全部服務器和雲數據都會聚合在一塊兒。傳統的方法是使用SNMP，監控支持該協議的網絡設備。數據能夠揭示長期的變化特色，這些是沒法由短期內運行的命令行工具得到的。若是發現懷疑的問題，多數的檢測方案會報警，此時及時分析進入下一階段。

　　問題的識別在服務器上是交互執行的，用標準的檢測工具來檢查系統的組件：CPU、磁盤、內存等等。一般是用vmstat、iostat、mpstat這樣的工具起一個命令行會話來完成的。還有一些較新的工具經過GUI支持的實時性能分析。

　　有些分析工具還具有tracing或者profiling的功能，用以對可疑區域作更深層次的檢查。作這類深層的分析可能須要定製工具乃至檢查源代碼。大量研究的努力就花在這裏，俺須要對軟件棧的層次作分離來找出問題的根本緣由。執行這類任務的工具包括stace、truss、pref、Dtrace

　　五個why

　　在分析階段，你還有一個能用的方法，叫作「五個why」技巧：問本身why？而後做答：

　　一、查詢多了數據庫性能就開始變差。why？

　　二、因爲內存換頁磁盤I/O延時。why？

　　三、數據庫內存用量變得太大了。why？

　　四、分配器消耗的內存比應該用的多。why？

　　五、分配器存在內存碎片的問題。why？

　　這是一個真實的例子，但出人意料的是要修復的是系統的內存分配庫。是持續的質問和對問題實質的深刻研究使得問題得以解決。

12、延時分析

　　延時分析檢查完成一項操做所用的時間，而後把時間再分紅小的時間段，接着對有着最大的延時的分析時間段作再次的劃分，最後定位並量化問題的根本緣由。與深度分析相同，延時分析也會深刻研究到軟件棧的各層來找到延時問題的緣由。

　　分析能夠從所施加的工做負載開始，檢查工做負載是如何在應用程序中處理的，而後深刻到操做系統的庫、系統調用、內核以及設備驅動。

　　舉個例子、Mysql的請求延時分析可能涉及到如下問題的回答：

　　一、存在請求延時的問題嗎？（是的）

　　二、請求時間大量花費在CPU上？（不在CPU上）

　　三、不花在CPU上的時間在等待什麼？（文件系統I/O）

　　四、文件系統的I/O時間是花在磁盤I/O上仍是鎖競爭上？（磁盤I/O）

　　五、磁盤I/O主要是隨機尋址的時間仍是數據傳輸的時間？（數據傳輸的時間）

　　對於這個問題，每一步所提出的問題都講延時劃分紅了兩個部分，而後繼續分析那個較大可能的部分：延時的二分搜索法，你能夠這麼理解，下圖

　　一旦是被出A和B中較慢的那個，就能夠對其作下一步的分析和劃分，依此類推。

　　數據庫查詢的延時分析是R方法的目的。

　　

 

　　　　　　　　　　　　延時分析過程

十3、R方法

　　R方法是針對Oracle數據庫開發的性能分析方法，意在找到延時的根源，基於Oracle的traceevents。它被描述成「基於時間響應性能提高方法，能夠獲得對業務的最大經濟收益」，着重於識別和量化查詢過程當中所消耗的時間，雖然它是用於數據庫研究領域，可是方法思想能夠應用於全部系統，做爲一種可能的研究手段，值得在此說起，

十4、事件跟蹤

　　系統的操做就是處理離散的事件，包括CPU指令、磁盤I/O，以及磁盤令、網絡包、系統調用、函數庫調用、應用程序事件、數據庫查詢等等。性能分析一般會研究這些事件的彙總數據，諸如每秒操做數，每秒的字節數、或者延時的均值。有時一些重要的細節信息不會出現這些彙總之中，所以最好的研究事件的方法是逐個檢查。

　　網絡排錯經常須要逐包檢查，用的工具備tcpdump，下邊這個例子將個個網絡包概括彙總成了一行行文字。

　　

　　

　　tcpdump按照須要能夠輸出各種信息

　　存儲設備I/O在塊設備層能夠用iosnoop來跟蹤

 　　

 

　　這裏打印出了一些時間戳，包括起始時間，終止時間，請求和完成之間的時間，以及服務這此次I/O的估計時間。

　　系統調用層是另外一個跟蹤的經常使用層，工具備Linux的strace和基於Solaris系統的truss。這些工具也有打印時間戳的選項。

　　當執行事件跟蹤時，須要找到如下信息：

　　一、輸入：事件請求的全部屬性，即類型、方向、尺寸等等

　　二、時間：起始時間、終止時間、延時

　　三、結果：錯誤狀態、事件結果

　　有時性能問題能夠經過檢查時間的屬性來發現，不管是請求仍是結果。事件的時間戳有利於延時分析，通常跟蹤工具都會包含這個功能。上述的tcpdump用參數-ttt，輸出所包含的DELTA時間，就測量了包與包之間的時間。

　　研究以前發生的事件也能提供信息。一個延時特別差的事件，一般叫作延時離羣值，多是由於以前的事件而不是自身所形成的。例如，隊列尾部時間的延時可能會很高，但這是由以前隊列裏的事件形成的，而並不是該時間自己。這種狀況只能用事件跟蹤來加以辨別。

十5、基礎棧統計

　　把當前的性能指標與以前的數值作比較，對分析問題經常有啓發做用。負載和資源使用的變化是可見的，能夠把問題回溯到他們剛發生的時候。某些觀測工具（基於內核計算器）能顯示啓動以來的信息統計，能夠用來與當前的活動作比較。雖然這比較粗糙，但總好過沒有。另外的方法就是作基礎棧統計。

　　基礎棧統計包括大範圍的系統觀測並將數據進行保存以備未來參考。與啓動以來的信息統計不一樣，後者會隱藏變化，基礎棧囊括了每秒的統計，所以變化是可見的。

　　在系統或應用程序變化的以前和以後都能作基礎棧統計，進而分析性能變化。能夠不按期的執行基礎棧統計並把它做爲站點記錄的一部分，讓管理員有一個參照。瞭解「正常」是什麼樣的。如果做爲性能檢測的一部分，能夠天天都按固定的間隔執行這類任務。

十6、靜態性能調整

　　靜態性能調整處理的是架構配置的問題。其餘的方法着重的是負載施加後的性能：動態性能。靜態性能分析是在系統空閒沒有施加負載的時候執行的。

　　作性能分析和調整，要對系統的全部組件確認如下問題：

　　一、該組件是須要的嘛？

　　二、配置是針對預期的工做負載設定的嘛？

　　三、組件的自動配置對於預期的工做負載時最優的嘛？

　　四、有組件出現錯誤嗎？是在降級狀態嗎？

　　下面是一些在靜態性能調整中可能發現的問題：

　　一、網絡接口協商：選擇100Mb/s而不是1Gb/s

　　二、創建RAID池失敗

　　三、使用的操做系統、應用程序或固件是舊的版本。

　　四、文件系統記錄的尺寸和工做負載I/O的尺寸不一致

　　五、服務器意外配置了路由

　　六、服務器使用的資源，諸如認證，來自遠端的數據中心，而不是本地的。

　　幸運的是，這些問題都很容易檢查。可貴是要記住作這些事情。

十7、緩存調優

　　從應用程序到磁盤，應用程序和操做系統都會部署多層的緩存來提升I/O性能。這裏介紹各級緩存的調優策略：

　　一、緩存的大小盡可能和棧的高度同樣。靠近工做執行的地方，減小命中緩存的資源開銷。

　　二、確認緩存開啓並確實在工做。

　　三、確認緩存的命中/失效比例和失效率

　　四、若是緩存的大小是動態的，確認它的當前尺寸。

　　五、針對工做負載調整緩存。這項工做依賴緩存的可調參數。

　　六、針對緩存調整工做負載。這項工做包括減小對緩存沒必要要的消耗，這樣能夠釋放更多空間來給目標負載使用。

　　要當心二次緩存--好比，消耗內存的兩塊不一樣的緩存塊，把相同的數據緩存了兩次。

　　還有，要考慮到每一層的緩存調優的總體性能收益。調整CPU的L1緩存能夠節省納秒級別的時間，當緩存失效時，用的是L2。提高CPU的L3緩存能避免訪問速度慢的多的主存，從而得到較大的性能收益。

十8、微基準測試

　　微基準測試測量的是施加的簡單的人造工做負載的 性能。微基準測試能夠用於執行科學方法，將假設和預測放到測試中驗證，或者做爲容量規劃的一部分來執行。

　　這與業界的基準定標是不一樣的，工業的基準定標是針對真實世界和天然的工做負載。這樣的基準定標執行時須要工做負載仿真，執行和理解的複雜度高。

　　微基準測試因爲涉及的因素較少，因此執行和理解會較爲簡單，能夠用微基準測試工具來施加工做負載並度量性能。或者用負載生成器來產生負載，用標準的系統工具來測量性能。兩種方法均可以，可是穩妥的方法時使用微基準測試工具並用標準系統工具再次確認性能數據。

　　下邊是一些微基準測試的例子，包括一些二維測試：

　　一、系統調用：針對fork（），exec（），open（），read（），close（）；

　　二、文件系統讀取：從緩存過的文件讀取，讀取數據大小從1B變化到1MB；

　　三、網絡吞吐量：針對不一樣的socket緩衝區的尺寸測試TCP端對端數據傳輸。

　　微基準測試一般在目標系統上的執行會盡量快，測量完成大量上述的這類操做所要的時間，而後計算均值（平均時間=運行時間/操做次數）