當一個系統運行緩慢性能下降的時候
很難知道原因是什麼
是內存洩漏
磁盤子系統瓶頸
還是某個特定應用程序在可擴展性方面有限制？有一些途徑可以發現和了解引起性能問題的根源
並且有可能消除它
本文給出了從哪裡入手的一些建議
文中介紹了如何著手性能方面的考慮以及如何定位常見的性能瓶頸
還介紹了與性能密切相關一些概念
比如私有的共享內存（ISM
Intimate Shared Memory）與優先內存頁面調度
文章重點是放在Solaris
和
操作環境下
著手性能問題 性能
或許比計算機系統其它方面的行為更需要有通盤的考慮
為了識別來自一個或多個組件的問題根源
必須要采取結構化的方法
實際的結果是
解決性能問題過程中最重要的一個部分是定義你正在試圖解決的問題
從實際應用的方面來講
這意味著定義一個操作或者測試用例
從而可以
A) 知道系統當前有多快
B) 知道系統需要快
X
倍
或者知道系統曾經在不同環境下快過
X
倍
設置基線是開始的第一步
性能分析是由簡單明確地定義所需解決的問題開始的自上而下的一個過程
如果你想要一個系統運行得快一些
你仍然需要定義這個系統的哪些屬性是你想要改進的
以及哪些代價是你可以接受或者不可以接受的
除非你能夠明確地描述出問題症狀/機會
想要識別出問題的根源只會是碰運氣
性能分析很象是偵探工作
我們通過證據和觀察建立事實依據
非常小心不要陷入預先想象的與事實不符的結論中——只有在具備非常壓倒性的證據時才確認猜想
對所有假設都要懷疑
其他人聲稱的事實實際上只是個可能正確也可能不正確的假設
如果這個假設是錯誤的
你可能會是在不正確的依據下工作
從而得出不正確的結論
這裡有一些警告
Solaris操作環境在大多數情形下對於工作負荷的自我性能優化都是很好的
發行版本越新
需要手工做的性能優化就越少
性能問題的根源經常被發現是因為一個試圖優化性能的行為引起的
首先需要注意應用程序
最後才是操作環境
任何對系統配置的更改
比如象內存大小和磁盤布局這樣的性能設置
都應該檢查其當前的正確性
同樣
一個帶參數的系統升級也有可能對新操作環境的性能帶來影響
性能監測 從暴露出來的問題開始
什麼操作使你看到性能問題的症狀？
比如說
是特定類型的數據庫查詢
文件或網絡操作比你期望的慢？在給出測試用例方面你能把操作步驟做到多具體
例如一個SQL查詢或者
行的C程序？
最大程度利用你的知識盡可能准確地說明
什麼地方出了什麼問題
以定義你的問題
良好的問題說明的例子就像這樣
一個SQL查詢在VXFS上比在UFS上要花兩倍的時間
SVR
消息隊列操作在操作環境版本A上比在操作環境版本B上要多花百分之
的時間
登錄進系統A比登錄進系統Y多花三倍的時間
一個問題說明不應該包括解決方法或者是可能的解決方法
在大部分的時候
對問題有一個清晰的說明就意味著完成了解決問題過程的一大半了
在對你試圖解決的問題進行說明的時候考慮到用戶觀點的因素也很重要
這意味著要從應用程序的角度來看
這和人們的天性相反
人們總是通過實驗試圖去證明或者證偽一個可能的原因
而不是依據觀察得到的事實來評估一個原因的可能性程度
不恰當的問題說明就象這樣
mpstat的
wt
列表明等待時間過多
用戶任務花時間太長
一個系統和它的應用程序的功能正確性問題與性能問題之間的邊界往往是一個灰色地帶
整個系統掛起與進程掛起的問題不在本文討論范圍之內
如果你懷疑系統的功能不正確
而不是性能問題
那麼給你的SUN解決方案中心打電話以找到一個解決問題的方法
高性能系統的前提是它的功能首先要正確
作為你積極的維護計劃的一部分
檢查/var/adm/messages中有沒有比如磁盤重試之類的硬件問題或者有沒有額外的消息產生也是很有價值的
察看系統的歷史信息也非常有價值
如果你的系統曾經有過更好的性能
畫一條時間曲線詳細記錄何時第一次發現性能變差以及從什麼時候開始性能一直很差
知道你的系統在正常情況下會怎樣
保存你的系統是如何正常運轉的樣例是一個好主意
你可以很容易地收集和保存每月的性能數據
比如
*stat類
vmstat
mpstat
iostat
vxstat
sar
ps的輸出以顯示哪些進程在運行 (在Solaris
操作環境下是prstat)
另外
有不少商業的和無支持的產品都可以用來做性能監測
一個免費的無支持的可選產品是SE Toolkit（要獲得其各種版本的信息
請看Sun Performance SE Toolkit page）
SE Toolkit報告磁盤活動
CPU利用情況
TCP和網絡連接
內存
以及其他更多信息
在我們的經驗裡
它安裝方便
不需要重啟系統
並且生成容易理解的圖形顯示
很多這類產品都存在一個共同的問題
就是對不同的硬件配置有不同的門限值
例如
特定的門限值對於
MHz的系統可能顯得太過
會讓這個系統慢得象是在爬一樣
但是對於一個
MHz的系統卻可能是可以接受的
尋找性能瓶頸
一旦你已經定義了需要解決的性能問題
下一步驟就是縮小范圍到瓶頸產生的地方
這個階段有必要問這樣一些問題
應用程序能告訴我它看到哪些是瓶頸？拿Oracle作例子
一個Oracle數據庫管理員應該知道BSTAT/ESTATS是什麼以及如何運行和理解它們
還是那句話
從應用程序的角度來看問題
BSTATS/ESTATS可以顯示限制了Oralce性能的瓶頸
這可以作為進一步分析的指導
大部分的時間花在哪裡
是內核還是用戶進程？通過vmstat
mpstat
sar
ps
prstat可以回答這個問題
具有相近類型的所有資源是否同樣繁忙？這個問題的意義在於尋找資源的不平等分布
比如
一個磁盤可能是瓶頸所在
或者一個CPU會比其他CPU更忙
對CPU
看mpstat
對磁盤
用iostat
哪個或哪些進程在使用最多的資源？用這些命令可以看到使用CPU和內存最多的進程
ps
eo pid
pcpu
args | sort +
n
CPU百分比
ps
eo pid
vsz
args | sort +
n
K字節的虛擬內存
/usr/ucb/ps aux |more
輸出被排序
使用CPU和內存最多的進程排在上面
Solaris
操作環境提供了prstat
它給出CPU和內存使用情況的一個動態注解
prstat
cvm的輸出結果非常有用
我們現在來看看怎用使用一些常見的Solaris命令來開始性能分析
vmstat
使用vmstat命令
vmstat命令是簡單的
這裡我們可以看到一個對於正在執行的應用程序
CPU能力不足的例子
% vmstat
procs memory page disk faults cpu
r b w swap free re mf pi po fr de sr m
m
m
m
in sy cs us sy id
vmstat輸出的第一行總是可以忽略
在
procs
下面標著
r
的一列是等待獲得CPU的進程運行隊列中的進程數
id
列是CPU空閒時間
這台機器沒有足夠的CPU資源以滿足進程運行的需要
這可以從它的大部分CPU時間花在用戶空間裡看出來(看
us
列)
這裡有兩種辦法可供采用——第一
增加更多的CPU
或者第二
對應用程序的代碼作性能分析看看是不是應用程序的某部分可以優化
對代碼片斷作優化可能會需要非常大量的努力——而且有時候收到的效果很少
在關系到時間的時候
最好在考慮你可能的
投資回報
時現實一點
mpstat
使用mpstat命令
mpstat命令報告每個處理器的統計信息
表格中的每一行代表一個處理器的活動情況
$ mpstat
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
From:http://tw.wingwit.com/Article/program/Oracle/201311/18626.html
