prstat： 系統 程序監控
下面将深入探讨 Solaris 工具 prstat(1)，幫助了解系統效用的全面實用 工具 。
prstat – 全面的實用工具
Solaris 中最重要、使用最廣的實用工具是 prstat（參見 prstat(1)）。prstat 可以快速回答以下問題：
*系統占用了多少 CPU 和記憶體？
*系統效用了哪些程序（或 使用者 、 zone 、項目、任務）？
*系統怎樣使用程序/線程（使用者綁定，I/O 綁定）？
在最簡單的形式中，prstat <interval>（即 prstat 2）将 檢測 所有程序并根據 CPU 使用率報告資料。
程序的順序根據目前的 CPU 使用率從高（最多）到低（最少）排列（% - 100% 表示所有系統 CPU 都完全利用）。對于清單中的每個程序，将列印以下資訊：
* PID：程序的程序 ID。
*USERNAME：真實使用者（登入）名稱或真實使用者 ID。
*SIZE：程序的總虛拟記憶體大小，以 K、M 或 G 為機關。
*RSS：程序的駐留集大小 (RSS)，以 K、M 或 G 為機關。
*STATE：程序的狀态 (cpuN/sleep/wait/run/zombie/stop)。
*PRI：程序的優先級。數字更大表示優先級更高。
*NICE：優先級計算中使用的 nice 值。隻有特定排程類中的程序才有 nice 值。
*TIME：程序的累計執行時間。
*CPU：程序使用的目前 CPU 時間的百分比。如果在非全局域中執行并且池裝置是活動的，百分比将是 zone 綁定的池所使用的處理器集合中處理器的百分比。
*PROCESS：程序的名稱（執行 檔案 的名稱）。
*NLWP：程序中 lwps 的數量。
prstat 的 <interval> 參數是采樣/重新整理的時間間隔（以秒為機關）。
專題報告
專題報告 – 排序
除了 CPU 使用率之外，prstat 輸出還可以按照其他名額排序。可以将 -s（降序）或 -S（升序）與名額選項一起使用（即 prstat -s time 2）：
标準 注釋
cpu 按照 CPU 使用率排序。這是預設設定。
pri 按照程序優先級排序。
rss 按照駐留集大小排序。
size 按照程序圖像排序。
time 按照程序執行時間排序。
專題報告 – 連續模式
對 prstat 使用選項 -c，新的報告将列印在上一個報告的下方，而不是覆寫它。這在收集檔案資訊時非常有用（即 prstat -c 2 > prstat.txt）。選項 -n <number of output lines> 可以用來設定報告的最大長度。
專題報告 – 使用者
對 prstat 使用 -a 或 -t 選項，将額外列印有關使用者的報告。
專題報告 – zone
對 prstat 使用 -Z 選項，将額外列印有關 zone 的報告。
專題報告 – 項目（參見 projects(1)）
對 prstat 使用 -J 選項，将額外列印有關項目的報告。
專題報告 – 任務（參見 newtask(1)）
對 prstat 使用 -T 選項，将額外列印有關任務的報告。
專題報告 – Microstate Accounting
與 其他每個時間周期或每個固定時間間隔（通常為百分之幾秒）收集 CPU 資料的作業系統不同，Solaris 10 合并了一種名為 Microstate Accounting 的技術，可以使用高分辨率時間戳測量每個時間的 CPU 資料，進而生成更為準确的資料統計。
Microstate Accounting 系統為線程和 CPU 維護準确的時間計數器。基于線程的 Microstate Accounting 跟蹤每個線程中幾個有意義的狀态，以及使用者和系統時間，包括陷阱時間、鎖定時間、睡眠時間和等待時間。prstat 按程序（選項 -m）或線程（選項 -mL）報告微觀狀态。
prstat 使用場景
prstat 使用場景 – cpu 時延問題
測量 CPU 飽和度的一個重要方法是 prstat 的時延問題（LAT 列）輸出。我們使用兩個 CPU 密集型應用程式副本（cc_usr）
prstat – 使用 CPU 密集型應用程式觀察時延問題
現在運作 prstat Microstate Accounting 報告，即 prstat -m 2 并記錄輸出：
prstat – prstat -m 2 輸出
請觀察最上面兩行輸出 PID 2223 和 PID 2224。可以清楚地看到兩個流程的 LAT 微觀狀态（CPU 時延問題）都有較高的時間百分比（分别是 50% 和 52%）。其餘時間如期花費在消耗方面（USR 微觀狀态）。此例清楚的表明，CPU 綁定應用程式争奪測試系統中惟一的一個 CPU，導緻為通路 CPU 需要很長的等待時間（時延問題）。
prstat 使用場景 – 高系統時間
現在運作系統調用集中型應用程式（cc_sys）并觀察 prstat 的輸出。首先，啟動一個 cc_sys 執行個體：
# cc_sys &
[1] 2310
#
prstat – 系統調用集中型應用程式
然後觀察 prstat -m 2 輸出：
prstat – prstat -m 2，系統調用集中型應用程式的輸出
注意最上方 PID 2310 那一行。清楚地發現流程 cc_sys 占用了高系統時間使用率 (61%)。還可以發現 ICX/VCX (277/22) 的比率很高，這說明該程序經常無意識關閉 CPU。
prstat 使用常見
prstat 使用常見 – 過度鎖定
經常可以看到，多處理器系統上應用程式的擴充性很差。根本原因之一可能在于，應用程式中的鎖定設計很差，導緻在同步時的等待時間過長。prstat 列 LCK 報告等待使用者鎖定花費的時間。
我 們看一個示例，一個示例程式實作了關鍵段的鎖定機制，使用的是讀/寫鎖定。該程式有 4 個線程需要通路共享的關鍵 zone 以進行讀取，還有一個線程以寫模式通路關鍵段。為了說明問題所在，有意減慢了寫入器的速度，以便它會占用關鍵段一段時間（對于讀取器這是有效的障礙）。
首先啟動程式，比如寫入器在關鍵段中花費了 0 毫秒（理想情況）。
# cc_lck 0 &
writer will sleep 0 useces
[1] 2626
#
cc_lck 0 – 在理想情況下運作
現在觀察每個線程的微觀狀态。使用 prstat -mL -p 2626 2。
cc_lck 0 – prstat 輸出
可以看到，所有 5 個線程幾乎争奪到了相等的計算機資源。因為不管是讀取器還是寫入器都沒有占用關鍵段很長的時間，沒有記錄等待時間。
現在重新執行整個測試，寫入器将等待 10 毫秒。
# cc_lck 10 &
writer will sleep 10 useces
[1] 2656
#
現在再次觀察微觀狀态。使用 prstat -mL -p 2656 2。
cc_lck 10 – prstat 輸出
這次情況似乎不太一樣了。有 4 個線程在等待關鍵段的鎖定期間花費的時間占總時間的 84%。另一方面，寫入器 (LWP #1) 有 (82%) 的時間在休眠。
在本例的應用程式中，如果檢視源代碼會發現存在明顯的鎖定問題，prstat Microstate Accounting 功能将幫助找出較大程式的鎖定弱點.