prstat：
系統 程序監控
下面將深入** solaris
工具 prstat(1)，幫助了解系統效用的全面實用
工具 。
prstat – 全面的實用工具
solaris 中最重要、使用最廣的實用工具是 prstat（參見 prstat(1)）。prstat 可以快速回答以下問題：
*系統占用了多少 cpu 和記憶體？
*系統效用了哪些程序（或
使用者 、 zone 、專案、任務）？
*系統怎樣使用程序/執行緒（使用者繫結，i/o 繫結）？
在最簡單的形式中，prstat （即 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 的 引數是取樣/重新整理的時間間隔（以秒為單位）。
專題報告 – 排序
除了 cpu 使用率之外，prstat 輸出還可以按照其他指標排序。可以將 -s（降序）或 -s（公升序）與指標選項一起使用（即 prstat -s time 2）：
標準 注釋
cpu 按照 cpu 使用率排序。這是預設設定。
pri 按照程序優先順序排序。
rss 按照駐留集大小排序。
size 按照程序影象排序。
time 按照程序執行時間排序。
專題報告 – 連續模式
對 prstat 使用選項 -c，新的報告將列印在上乙個報告的下方，而不是覆蓋它。這在收集檔案資訊時非常有用（即 prstat -c 2 > prstat.txt）。選項 -n 可以用來設定報告的最大長度。
專題報告 – 使用者
對 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 使用場景 – 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 列 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 功能將幫助找出較大程式的鎖定弱點.
PRTG 監控系統程序的方法
想要用prtg去監控系統程序是否正常執行，snmp協議是不行的，可以使用windows自帶乙個外掛程式wmi去實現監控系統程序 第一步 在需要監控的伺服器上把wmi開啟 services.msc wmi performance adapter 第二步 啟動remote procedure call ...
linux 程序監控
1 ps命令 直接在linux系統中輸入 ps 結果如下 預設情況下，ps命令指揮顯示執行在當前控制台下的屬於當前使用者的程序。pid 程式的程序號 tty 程式執行的終端 time 程式執行的時間 引數 在linux系統中，程序的狀態有五種 1.執行 正在執行或在執行佇列中等待 2.中斷 休眠中,...
supervise 程序監控
daemontools讓程序保持通話 linux下程序有時候會莫名的斷掉，我在使用舊版mysql proxy的時候就時常被問題困惱，俗話說 不怕賊偷，就怕賊惦記著 程序斷掉並不可怕，可怕的是沒有任何先兆，稀里糊塗的就斷了，究其原因，一來可能是誤操作引起來的，二來可能是軟體本身的bug造成的，三來也可...