Linux 系統的性能評估和調優指南

　　對服務器來說主要的角色就是應用服務器或數據庫服務器，CPU作為關鍵資源經常成為性能瓶頸的根源。CPU使用率高并不總是意味著CPU工作繁忙，它有可能是正在等待其他子系統。在進行性能分析時，將所有子系統當做一個整體來看是非常重要的，因為在子系統中可能會出現瀑布效應。

　　注釋：有種常見的錯誤觀念認為CPU是服務器中最重要的。情況不總是這樣，服務器經常是CPU的配置高，硬盤、內存和網絡子系統是低配置。只有一些特定對CPU要求高的應用程序才能真正充分利用當今的高端處理器。

　　3.2.1 發現CPU瓶頸

　　有多種方法可以來確認CPU瓶頸。在第二章“監控和基準工具”中介紹到，Linux有很多工具幫助我們確認瓶頸，問題是使用哪一個。

　　其中一個工具是uptime。通過分析uptime輸出，我能對在過去15分鐘所發生的事情有個粗略的了解。關于此工具的更多說明，參見2.3.3“uptime”。

　　例子3-1：一個系統CPU資源緊張的uptime輸出結果

　　----------------------------------------------------------------------------------------

　　18:03:16 up 1 day, 2:46, 6 users, load average: 182.53, 92.02, 37.95

　　----------------------------------------------------------------------------------------

　　使用KDE System Guard和CPU傳感器可以讓你了解當前CPU的工作負載。

　　提示：小心不要因為同時運行過多的工具而導致CPU問題。你可能發現當同時使用多個不同監控工具時會使CPU負載過高。

　　使用top，你可以看到CPU使用率及主要是哪些進程引起問題(例子2-1)。如果你已安裝sar，搜集了包括CPU使用率的信息。但分析這些信息是很困難的，所以要使用isag，它可以將sar的輸出轉換成圖形。否則你可以通過腳本解析這些信息并使用電子表格繪制CPU使用率的趨勢圖。你也可以在命令行中輸入sar -u或者sar -U processornumber。要獲得比單單CPU子系統更多關于系統及當前使用率的信息，一個不錯的工具就是vmstat(參見2.3.2，“vmstat”)

　　3.2.2 SMP

　　基于SMP的系統會出現其特有且難于檢測的問題。在SMP環境中，有個叫CPU親和力【affinity】的概念，它允許你將一個進程綁定到指定的CPU。

　　主要用途是這有利于CPU cache的優化，它通過讓進程在同一CPU運行代替在處理器間移動來實現。當進程在CPU間移動時，新CPU的cache會被清空。因此一個進程在處理器間移動會發生多次cache清空，這意味著一個單獨的進程會花費更多的時間才能完成。這種情況非常難于發現，因為在監控時CPU負載可能非常均衡，不一定會出現某個CPU達到峰值的情況。親和力在基于NUMA的系統中也很有用如IBM System x 3950，where it is important to keep memory, cache, and CPU access local to one another.

　　3.2.3 性能調校選項

　　首先要確認系統性能問題是由CPU導致的而不是其他子系統。如果處理器為服務器瓶頸，可以通過相應調整來改善性能，這包括：

　　▶ 使用ps -ef命令確保沒有不必要的程序在后臺運行。如果發現有不必要的程序，將其停止并使用cron將其安排在非高峰期運行。

　　▶ 通過使用top命令找出非關鍵性且消耗CPU較多的進程，并使用renice命令修改它們的優先級。

　　▶ 在基于SMP的機器中，嘗試使用taskset將進程綁定到指定的CPU，確保進程不需要在處理器間忙碌，從而導致多次cache清空。

　　▶ 對于正在運行的應用程序，最好的辦法是縱向升級(提升CPU頻率)而不是橫向升級(增加CPU數量)。這取決于你的應用程序是否能使用到多個處理器。例如一個單線程應用程序的升級方式最好是更換成更快的CPU而不是增加為多個CPU。

　　▶ 通常的做法還包括確認你所使用的是最新的驅動程序和韌體，因為這會影響CPU的負載。

　　下面的步驟可用來作為快速調優的策略：

　　1. 了解你的系統。

　　2. 備份系統。

　　3. 監控和分析系統性能。

　　4. 縮小瓶頸范圍，找出原因。

　　5. 修復導致瓶頸的原因，每次只做一個變更。

　　6. 回到第3步，直到系統性能達到滿意。

　　提示：你應該將每一個步驟記錄在文件中，特別是你針對性能所做的變更和及其影響。

　　3.1.1 搜集信息

　　大多數情況下，你所能得到的第一手信息就是“服務器出現了問題”。所以利用一些探索性問題來弄清和記錄下問題是非常重要的。這里列出一些問題用來幫助你更好的了解系統。

　　▶ 你能給我關于所涉及服務器的完整信息嗎?

　　- 型號

　　- 使用年限

　　- 配置

　　- 外圍設備

　　- 操作系統版本和更新等級

　　▶ 你能告訴我究竟出現了什么問題?

　　- 都有哪些癥狀?

　　- 描述一下錯誤信息。

　　對于有些人回答這個問題有些困難，但用戶提供的任何額外信息都有可能幫助你找到問題。例如，用戶可能說“當我拷貝文件到服務器時速度真的很慢。”。這就暗示網絡有問題或硬盤子系統有問題。

　　▶ 誰受到這個問題的影響?

　　一個人、某些人還是整個組織受這個問題的影響?這可以幫助你判斷問題是否出現在某段特定的網絡中還是與應用相關等等。如果只有一個用戶受此問題影響，很可能是用戶的PC出了問題(或者是他們想象出來的)。

　　The perception clients have of the server is usually a key factor.從這個觀點來說，性能問題并不一定與涉及服務器直接有關：位于服務器和客戶端的網絡極易成為導致問題的原因，這包括網絡設備和其他提供服務的服務器，例如域控制器。

　　▶ 問題是否可以重現?

　　所有可以重現的問題都能被解決。如果你在系統方面經驗豐富，你應該能找出問題根源并采取相應的措施。

　　問題的重現可以讓你更好的了解和明白此問題。記錄重現問題的相關步驟是十分必要的：

原文轉自：http://www.redbooks.ibm.com/abstracts/redp4285.html