當一個系統(tǒng)運行緩慢性能下降的時候，很難知道原因是什么。是內(nèi)存泄漏，磁盤子系統(tǒng)瓶頸，還是某個特定應(yīng)用程序在可擴展性方面有限制？有一些途徑可以發(fā)現(xiàn)和了解引起性能問題的根源，并且有可能消除它。本文給出了從哪里入手的一些建議。文中介紹了如何著手性能方面的考慮以及如何定位常見的性能瓶頸，還介紹了與性能密切相關(guān)一些概念，比如私有的共享內(nèi)存（ISM-Intimate Shared Memory）與優(yōu)先內(nèi)存頁面調(diào)度。文章重點是放在Solaris 2.6操作環(huán)境下。
著手性能問題
性能，或許比計算機系統(tǒng)其它方面的行為更需要有通盤的考慮。為了識別來自一個或多個組件的問題根源，必須要采取結(jié)構(gòu)化的方法。
實際的結(jié)果是，解決性能問題過程中最重要的一個部分是定義你正在試圖解決的問題。從實際應(yīng)用的方面來講，這意味著定義一個操作或者測試用例，從而可以：
A) 知道系統(tǒng)當前有多快。
B) 知道系統(tǒng)需要快"X"倍；或者知道系統(tǒng)曾經(jīng)在不同環(huán)境下快過"X"倍。
設(shè)置基線是開始的第一步。性能分析是由簡單明確地定義所需解決的問題開始的自上而下的一個過程。如果你想要一個系統(tǒng)運行得快一些，你仍然需要定義這個系統(tǒng)的哪些屬性是你想要改進的，以及哪些代價是你可以接受或者不可以接受的。除非你能夠明確地描述出問題癥狀/機會，想要識別出問題的根源只會是碰運氣。
性能分析很象是偵探工作，我們通過證據(jù)和觀察建立事實依據(jù)，非常小心不要陷入預(yù)先想象的與事實不符的結(jié)論中——只有在具備非常壓倒性的證據(jù)時才確認猜想。
對所有假設(shè)都要懷疑。其他人聲稱的事實實際上只是個可能正確也可能不正確的假設(shè)。如果這個假設(shè)是錯誤的，你可能會是在不正確的依據(jù)下工作，從而得出不正確的結(jié)論。
這里有一些警告。Solaris操作環(huán)境在大多數(shù)情形下對于工作負荷的自我性能優(yōu)化都是很好的。發(fā)行版本越新，需要手工做的性能優(yōu)化就越少。性能問題的根源經(jīng)常被發(fā)現(xiàn)是因為一個試圖優(yōu)化性能的行為引起的。首先需要注意應(yīng)用程序，最后才是操作環(huán)境。
任何對系統(tǒng)配置的更改，比如象內(nèi)存大小和磁盤布局這樣的性能設(shè)置，都應(yīng)該檢查其當前的正確性。同樣，一個帶參數(shù)的系統(tǒng)升級也有可能對新操作環(huán)境的性能帶來影響。
性能監(jiān)測
1. 從暴露出來的問題開始
什么操作使你看到性能問題的癥狀？
比如說，是特定類型的數(shù)據(jù)庫查詢，文件或網(wǎng)絡(luò)操作比你期望的慢？在給出測試用例方面你能把操作步驟做到多具體，例如一個SQL查詢或者30行的C程序？
最大程度利用你的知識盡可能準確地說明“什么地方出了什么問題”以定義你的問題。良好的問題說明的例子就像這樣：
一個SQL查詢在VXFS上比在UFS上要花兩倍的時間。
SVR4消息隊列操作在操作環(huán)境版本A上比在操作環(huán)境版本B上要多花百分之30的時間。
登錄進系統(tǒng)A比登錄進系統(tǒng)Y多花三倍的時間。
一個問題說明不應(yīng)該包括解決方法或者是可能的解決方法。
在大部分的時候，對問題有一個清晰的說明就意味著完成了解決問題過程的一大半了。在對你試圖解決的問題進行說明的時候考慮到用戶觀點的因素也很重要，這意味著要從應(yīng)用程序的角度來看。這和人們的天性相反，人們總是通過實驗試圖去證明或者證偽一個可能的原因，而不是依據(jù)觀察得到的事實來評估一個原因的可能性程度。
不恰當?shù)膯栴}說明就象這樣：
mpstat的"wt"列表明等待時間過多。
用戶任務(wù)花時間太長。
一個系統(tǒng)和它的應(yīng)用程序的功能正確性問題與性能問題之間的邊界往往是一個灰色地帶。整個系統(tǒng)掛起與進程掛起的問題不在本文討論范圍之內(nèi)。如果你懷疑系統(tǒng)的功能不正確，而不是性能問題，那么給你的SUN解決方案中心打電話以找到一個解決問題的方法。高性能系統(tǒng)的前提是它的功能首先要正確。
作為你積極的維護計劃的一部分，檢查/var/adm/messages中有沒有比如磁盤重試之類的硬件問題或者有沒有額外的消息產(chǎn)生也是很有價值的。
察看系統(tǒng)的歷史信息也非常有價值；如果你的系統(tǒng)曾經(jīng)有過更好的性能，畫一條時間曲線詳細記錄何時第一次發(fā)現(xiàn)性能變差以及從什么時候開始性能一直很差。
2. 知道你的系統(tǒng)在正常情況下會怎樣
保存你的系統(tǒng)是如何正常運轉(zhuǎn)的樣例是一個好主意。你可以很容易地收集和保存每月的性能數(shù)據(jù)，比如：
*stat類：vmstat, mpstat, iostat, vxstat,sar
ps的輸出以顯示哪些進程在運行 (在Solaris 8操作環(huán)境下是prstat)。另外，有不少商業(yè)的和無支持的產(chǎn)品都可以用來做性能監(jiān)測。一個免費的無支持的可選產(chǎn)品是SE Toolkit（要獲得其各種版本的信息，請看Sun Performance SE Toolkit page）。SE Toolkit報告磁盤活動、CPU利用情況、TCP和網(wǎng)絡(luò)連接、內(nèi)存，以及其他更多信息。在我們的經(jīng)驗里，它安裝方便，不需要重啟系統(tǒng)，并且生成容易理解的圖形顯示。
很多這類產(chǎn)品都存在一個共同的問題，就是對不同的硬件配置有不同的門限值。例如，特定的門限值對于400-MHz的系統(tǒng)可能顯得太過，會讓這個系統(tǒng)慢得象是在爬一樣，但是對于一個900-MHz的系統(tǒng)卻可能是可以接受的。
3. 尋找性能瓶頸
一旦你已經(jīng)定義了需要解決的性能問題，下一步驟就是縮小范圍到瓶頸產(chǎn)生的地方。
這個階段有必要問這樣一些問題：
應(yīng)用程序能告訴我它看到哪些是瓶頸？拿Oracle作例子，一個Oracle數(shù)據(jù)庫管理員應(yīng)該知道BSTAT/ESTATS是什么以及如何運行和理解它們。還是那句話，從應(yīng)用程序的角度來看問題，BSTATS/ESTATS可以顯示限制了Oralce性能的瓶頸，這可以作為進一步分析的指導。
大部分的時間花在哪里，是內(nèi)核還是用戶進程？通過vmstat、mpstat、sar、ps、prstat可以回答這個問題。
具有相近類型的所有資源是否同樣繁忙？這個問題的意義在于尋找資源的不平等分布。比如，一個磁盤可能是瓶頸所在，或者一個CPU會比其他CPU更忙。對CPU，看mpstat。對磁盤，用iostat。哪個或哪些進程在使用最多的資源？用這些命令可以看到使用CPU和內(nèi)存最多的進程：
ps -eo pid,pcpu,args | sort +1n |
CPU百分比：
ps -eo pid,vsz,args | sort +1n |
/usr/ucb/ps aux |more |
輸出被排序，使用CPU和內(nèi)存最多的進程排在上面。
Solaris 8操作環(huán)境提供了prstat，它給出CPU和內(nèi)存使用情況的一個動態(tài)注解。prstat -cvm的輸出結(jié)果非常有用。
我們現(xiàn)在來看看怎用使常見的Solaris命令來開始性能分析。
vmstat命令是簡單的。這里我們可以看到一個對于正在執(zhí)行的應(yīng)用程序，CPU能力不足的例子。
% vmstat 15 procs memory page disk faults cpu r b w swap free re mf pi po fr de sr m0 m1 m2 m3 in sy cs us sy id 45 0 0 2887216 182104 3 707 449 6 455 0 80 2 6 1 0 1531 5797 983 61 30 9 58 0 0 2831312 46408 5 983 582 56 3211 0 492 0 0 0 0 1413 4797 1027 69 31 0 55 0 0 2830944 56064 2 649 656 3 806 0 121 0 0 0 0 1441 4627 989 69 31 0 57 0 0 2827704 48760 4 818 723 6 800 0 121 0 0 1 0 1606 4316 1160 66 34 0 56 0 0 2824712 47512 6 857 604 56 1736 0 261 0 0 1 0 1584 4939 1086 68 32 0 58 0 0 2813400 47056 7 856 673 33 2374 0 355 0 0 0 0 1676 5112 1114 70 30 0 60 1 0 2816712 49464 7 861 720 6 731 0 110 7 0 3 0 2329 6131 1067 64 36 0 58 0 0 2817552 48392 4 585 521 0 996 0 146 0 0 0 0 1357 6724 1059 71 29 0 |
vmstat輸出的第一行總是可以忽略。在"procs"下面標著"r"的一列是等待獲得CPU的進程運行隊列中的進程數(shù)。"id"列是CPU空閑時間。這臺機器沒有足夠的CPU資源以滿足進程運行的需要，這可以從它的大部分CPU時間花在用戶空間里看出來(看"us"列)。
這里有兩種辦法可供采用——第一，增加更多的CPU，或者第二，對應(yīng)用程序的代碼作性能分析看看是不是應(yīng)用程序的某部分可以優(yōu)化。對代碼片斷作優(yōu)化可能會需要非常大量的努力——而且有時候收到的效果很少。在關(guān)系到時間的時候，最好在考慮你可能的“投資回報”時現(xiàn)實一點。
