3. 尋找性能瓶頸
一旦你已經定義了需要解決的性能問題，下一步驟就是縮小範圍到瓶頸產生的地方。
這個階段有必要問這樣一些問題：
應用程式能告訴我它看到哪些是瓶頸？拿Oracle作例子，一個Oracle數據庫管理員應該知道BSTAT/ESTATS是什麼以及如何運行和理解它們。還是那句話，從應用程式的角度來看問題，BSTATS/ESTATS可以顯示限制了Oralce性能的瓶頸，這可以作為進一步分析的指導。
大部分的時間花在哪，是內核還是用戶進程？通過vmstat、mpstat、sar、ps、prstat可以回答這個問題。
具有相近類型的所有資源是否同樣繁忙？這個問題的意義在於尋找資源的不平等分佈。比如，一個磁片可能是瓶頸所在，或者一個CPU會比其他CPU更忙。對CPU，看mpstat。對磁片，用iostat。 哪個或哪些進程在使用最多的資源？用這些命令可以看到使用CPU和記憶體最多的進程：
ps -eo pid,pcpu,args | sort +1n
|
CPU百分比：
ps -eo pid,vsz,args | sort +1n
|
K字節的虛擬記憶體：
輸出被排序，使用CPU和記憶體最多的進程排在上面。
Solaris 8操作環境提供了prstat，它給出CPU和記憶體使用情況的一個動態注解。prstat -cvm的輸出結果非常有用。
我們現在來看看怎用使常見的Solaris命令來開始性能分析。
vmstat命令是簡單的。這裡我們可以看到一個對於正在執行的應用程式，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的進程運行隊列中的進程數。"id"列是CPU空閒時間。這台機器沒有足夠的CPU資源以滿足進程運行的需要，這可以從它的大部分CPU時間花在用戶空間裏看出來(看"us"列)。
這裡有兩種辦法可供採用——第一，增加更多的CPU，或者第二，對應用程式的代碼作性能分析看看是不是應用程式的某部分可以優化。對代碼片斷作優化可能會需要非常大量的努力——而且有時候收到的效果很少。在關係到時間的時候，最好在考慮你可能的“投資回報”時現實一點。（T004）
<<上一頁
1
2
