Linux性能優化1.1 常用建議

<b>摘要</b>

性能追蹤建議

沒有遠見和規劃，這樣解決性能問題是痛苦的。産生問題的原因一次又一次從指尖溜走，不僅浪費時間并且讓你備感受挫。但是，如果按照正确的步驟，就可以把令人沮喪的性能追蹤轉變為有趣的偵探故事。每一條資訊都讓你更接近問題的根源。人不可能總是可信的，證據将是你唯一的朋友。當你開始研究問題的時候，會遇到不尋常的波折，追蹤之初發現的資訊最後可能會幫你解決問題。最棒的部分就是，當你最終逮住“壞小子”并修複問題時，會感覺到腎上腺素的刺激和成就感。

如果你從來沒有調查過性能問題，那麼第一步會是決定性的。不過，聽從下面幾個明顯或隐晦的建議，可以節約時間，并按照自己的方式來找出性能問題的原因。本章目标是提供一系列建議和指導來幫助讀者追蹤性能問題。在研究系統或應用程式出現的問題時，這些建議告訴你怎樣避開一些常見的陷阱。這些建議，大多數都是從浪費的時間和令人沮喪的死胡同中辛苦得到的教訓，它們有助于快速并有效地解決你的性能問題。

閱讀本章後，你将能夠：

避免重複他人的工作。

避免重複自己的工作。

避免因收集的誤導資訊而導緻的虛假線索。

為你的研究建立有用的參考文檔。

盡管所有的性能調查都是有瑕疵的（“如果一開始就能想到”是你的口頭禅），但這些建議将會幫助你避免性能研究中的一些常見錯誤。

<b></b>

<b>1.1　常用建議</b>

1.1.1　記大量的筆記（記錄所有的事情）

在調查性能問題時，你可以做的最重要的事情大概就是記錄下看到的每一個輸出、執行的每一條指令，以及研究的每一個資訊。結構清晰的記錄能讓你隻檢視記錄就可以檢驗關于性能問題原因的猜想，而不是重新運作測試。這能節約大量時間。寫下來并且建立性能記錄。

在性能調查之初，我通常會為其建立一個目錄，在gnu emacs中打開一個新的“notes”檔案，開始記錄系統的資訊。之後，将性能結果儲存到這個目錄，并将有意思的和相關的資訊儲存到notes檔案。建議将下面的内容添加到你的性能調查檔案和目錄中：

記錄硬/軟體的配置情況—記錄下的資訊包括硬體配置（主存容量、cpu類型、網絡和磁盤子系統）和軟體環境（os和軟體的版本、相關配置檔案）。這些資訊看上去很容易在之後重制，但是在追蹤問題時，你可能會大幅度地修改系統配置。認真細緻的筆記有助于在特定的測試過程中弄清楚系統配置。

示例：每次測試時，儲存cat  /proc/pci、dmesg和uname  -a的輸出。

儲存并組織性能結果—運作很長時間後還能評估性能結果是很有價值的。記錄系統配置的同時，也記錄測試結果。這使你得以比較不同的配置是如何影響性能結果的。如果需要，可以重新運作測試，但是測試一種配置是耗費時間的過程。隻需讓筆記保持條理清晰，避免重複工作則效率更高。

寫下指令行調用—在運作性能工具時，常常需要用困難複雜的指令行來準确定位到你感興趣的系統區域進行測量。如果想重新測試，或在不同的應用程式上運作相同的測試，那麼，複制這些指令行不僅令人厭煩，并且在初次嘗試時，不容易做對。更好的辦法是準确記錄下你鍵入的資訊。這樣在之後的測試中就能夠完全重制指令行，而在回顧之前測試結果時，也可以看到你測量的内容。linux指令script（詳見第8章）或者從終端“剪切粘貼”都是完成這項工作的好方法。

記錄研究資訊和url—調查性能問題時，将在網際網路上發現的相關資訊記錄下來是很重要的，不論發現的途徑是電子郵件，還是人際交往。如果你找到一個看上去相關的網站，就把它剪切粘貼到你的筆記中。（網站是會消失的。）當然，還要記錄下url，因為你可能在之後還要檢視這個網頁，或者網頁所指資訊對後面的調查會變得重要起來。

在收集和記錄所有這些資訊時，你可能會疑惑：這樣做值得嗎？有些資訊眼下顯得毫無作用或有誤導性，但它在将來可能是有用的。（好的性能調查就像一部優秀的偵探劇：盡管開始的時候所有的線索都令人迷惑，但最終都會真相大白。）在調查問題時，請牢記以下幾點：

結果的含義可能是不明确的—性能工具給你的資訊并不總是清晰明了的。有的時候，你需要更多的資訊才能了解某個結果的含義。之後，你可以回過頭以新的視角重新審視那些看似無用的測試結果。實際上，舊資訊可能會駁斥或者證明關于性能問題本質的某個特定理論。

所有的資訊都是有用的（這也就是你要記錄的原因）—記錄已運作的測試資訊以及系統配置資訊的原因不見得會立即明晰。這一點在你試圖向開發人員或管理人員解釋系統性能不佳的原因時是非常有用的。通過記錄和整理調查過程中你所見的一切，你就有證據支援特定理論，同時也具備大量的測試結果來證明或駁斥其他理論。

定期回顧你的筆記可以得到新的想法—當你為性能問題積攢了大量的資訊時，那就定期回顧它們。重新審視會讓你關注結果，而不是測試。當許多測試結果放在一起被同時檢視時，問題的原因也許就會自動浮現。回顧你收集的資料，就可以在不實際運作任何測試的情況下進行理論檢驗。

在調查問題時，重做一些工作雖然是不可避免的，但是，在重做工作上花費的時間越少，你的效率就越高。如果你寫了大量的筆記，并有辦法在發現資訊時記錄它們，那麼你就可以依賴已經做過的工作，而避免重複運作測試以及重複研究。保持筆記的可靠性和一緻性，進而節省時間減少挫折。

例如，在調查性能問題後，最終确定為硬體原因（主存慢、cpu慢等），你可能會想通過更新慢速硬體，并重新運作測試來檢驗這個想法。通常要花一點時間才能獲得新硬體，而在你可以重新運作測試之前可能已經過了很久。當最終可以開始的時候，你想要在新老硬體上運作同樣的測試。如果你已經儲存了之前的測試調用和測試結果，那麼，你馬上就知道要怎樣為新硬體進行測試設定，同時也可以比較新的結果與儲存的舊結果。

1.1.2　自動執行重複任務

當開始調整系統改進性能時，鍵入複雜指令行很容易出現錯誤，而無意中使用的不正确參數和配置則會産生誤導性的性能資訊。是以，自動執行性能工具調用和應用程式測試是一個好辦法：

性能工具調用—有些linux性能工具的指令行相當複雜，給自己省點力，把它們儲存到一個shell腳本中，或是将所有指令都放到可以進行剪切粘貼的參考檔案中。這可以讓你少受些挫折，并且讓你多少有些信心：用來調用工具的指令行是正确的。

應用程式測試—大部分應用程式有着複雜的配置，要麼通過指令行，要麼通過配置檔案。你會經常重新運作要多次測試的應用程式，若将調用儲存為腳本，就能少走彎路。雖然剛開始的時候，鍵入30個字元的指令看上去很容易，但這樣的操作重複10次後，你就會向往自動執行了。

盡可能多地自動執行，就能減少錯誤。使用腳本自動執行，可以節省時間，并有助于避免因不當工具和測試調用造成的誤導性資訊。

舉個例子，你想在特定工作負載下或某段時間内監控系統，但是在測試結束時，你可能不在現場。這種情況下，腳本就很好用了，在測試完成時，可以自動收集、命名、儲存全部生成的性能資料，并将它們自動放到“results”目錄中。有了這些基礎之後，你就能按照不同的優化和調整重新運作測試，并且不用擔心資料是否已經儲存好。你反而可以集中精力找出問題的原因，而不是去管理測試結果。

1.1.3　盡可能選擇低開銷工具

一般情況下，觀察系統會修改系統的行為。（對實體愛好者來說，這就是海森堡（heisenberg）不确定性原理。）

具體而言，在使用性能工具時，它們會改變系統的行為方式。調查問題的時候，你想要看看應用程式是如何執行的，同時還必須處理性能工具引發的錯誤。這是不可避免的弊端，但是你要知道它的存在，并努力将其最小化。有些性能工具能夠給出高度精确的系統資訊，但其檢索資訊的開銷也很高。高開銷工具對系統行為帶來的變化大于低開銷工具。如果你隻需要了解系統的粗略資訊，那麼使用低開銷的工具是更好的選擇，即使它們不夠準确。

例如，對于正在使用的應用程式，工具ps能給出其主存數量和類型的相當不錯但粗糙的概況。那些準确性更高，但是影響較大的工具，如memprof或valgrind，雖然也能提供這些資訊，但是它們消耗的主存和cpu資源比隻使用原始應用程式要大，是以會改變系統行為。

1.1.4　使用多個工具來搞清楚問題

雖然在找出性能問題原因的時候，如果隻需要用一個工具那将是非常友善的，但這種情況相當少見。實際上，你使用的每一種工具都會為問題的原因提供線索，是以，你必須同時使用多個工具來真正搞清楚發生了什麼。比如，一種性能工具會告訴你系統存在大量的磁盤i/o，而另一種工具則告訴你系統使用了大量的交換。如果隻以第一個工具的結論制定解決方案，你可能會簡單地選擇更快的磁盤驅動器（然後發現性能問題僅僅改善了一點點）。而将兩種工具的結果放在一起，你就會判斷出：大量的磁盤i/o是由大量使用的交換造成的。在這種情況下，你可能會買更多的主存以減少交換（這樣就不會再有大量的磁盤i/o）。

比起單一地使用任何一種工具，同時使用多個性能工具通常能讓你對性能問題有更清晰的了解。

寓言：盲人摸象

三個盲人在一頭大象旁邊，想要搞清楚它長什麼樣子。第一個人拉住了尾巴，說道：“大象就像一根繩子。”第二個人摸到了象腿，說道：“大象像一棵樹。”第三個人摸到了大象一側的身體，說道：“大象像一堵厚實的牆。”

顯然，沒有一個人得出了正确的答案。如果他們将各自的印象進行共享群組合，那麼，他們就可能發現大象真正的模樣。别做摸象的盲人。同時使用多種性能工具找出問題的原因。

1.1.5　相信你的工具

性能追蹤的過程中，最令人興奮又令人沮喪的時刻之一，就是工具顯示了一個“不可能”的結果。某些“不會”發生的事情卻明明白白地發生了。第一反應會認為工具壞了。不要被直覺愚弄了，工具是公正的。雖然它們可能會不正确，但這更有可能是因為應用程式做了不該做的事情。要使用工具來調查問題。

舉個例子，gnome電腦使用超過2000個系統調用隻為了實作加載和退出。如果沒有性能工具來證明這個事實，那麼，僅僅為了啟動和停止應用程式就需要如此之多的系統調用看上去是沒有必要的。但是性能工具能夠顯示其發生的位置和原因。

1.1.6　利用其他人的經驗（慎重）

在調查任何一個性能問題時，你可能會發現問題令人不知所措。不要獨自面對它。問問開發者是否見過同樣的問題。試着找到其他解決過你所遇問題的人。在網際網路上搜尋類似的問題，并希望找到解決方案。給使用者和開發人員發電子郵件。

本條建議附帶一個提醒：即使開發者認為了解自己的應用程式，他們也不見得總是對的。如果開發者不認同性能工具的資料，那麼，他們也許是錯的。向開發者展示你的資料以及你為何會得出這樣的結論。他們通常會幫你重新解釋資料或者解決問題。不論是哪種情況，都會将你的調查向前推進一些。如果你的資料表明發生了不該發生的事情，就不要害怕與開發者有分歧。

比如，你通常可以按照在google上搜尋類似問題得到的指導來解決性能問題。很多時候，在調查一個linux問題時，你會發現之前已經有人遇到過了（即使是幾年前），而且還在公共郵件清單中報告了解決方法。使用google是很容易的，它可以為你節省幾天的工作量。