AIX性能監控topas命令的詳細解析

操作系統的最全面動態，而又查看方便的性能視圖就是topas命令了，下面以topas輸出爲例，對AIX系統的性能監控做簡要描述，供運維工程師和系統管理員們參考。

另：1.操作系統報錯信息errpt查看。2.磁盤空間使用率採用df查看。這裏主要分析性能問題。

 

執行topas命令後如圖所示：

#topas

 

區域1：反映CPU使用率和工作狀況。

Kernel：
說明：操作系統的內核佔用的CPU時間比率。
操作系統作爲基礎軟件，爲應用程序支持和服務的同時，本身的運行也需要一定的CPU和內存資源（順便提到內存資源，後面不再闡述這個內容了），特別是內存資源，系統負載越重，相應的內核佔用的CPU和內存資源也會越多。一般來說，內核佔用的CPU時間不會太多的。一般小於應用的CPU使用率。

User：
說明：用戶進程佔用的CPU時間比率。
這個爲CPU使用率的關鍵數值。該使用率反映了用戶在操作系統基礎上運行的各種軟件佔用的CPU時間比率的總和。一般來說，如果User+Kernel連續大於70%，即可以認爲系統可能存在CPU上的嚴重性能問題。

Wait
說明：CPU處於等待狀態佔CPU時間的比率。
CPU的等待一般都爲等待IO的響應，衆所周知，目前計算機的主要瓶頸都在IO。應用程序執行的時候，需要讀寫磁盤等外部存儲的數據，進程就會發起IO請求後等待IO完成。這個等待的過程佔用CPU時間就是wait。當這個值很高的時候，就說明IO來不及響應很多的IO請求，這個時候，就只能從IO層面想辦法優化了。

Idle：
說明：CPU空閒時間比率，這個就不用說了吧。就是CPU多少時間比率在閒着。
CPU佔用率出問題的主要可能原因：數據庫服務器執行某一個SQL或者存儲過程（存儲過程就是封裝起來的sql程序包而已）需要大量的運算（一般爲軟件設計不合理）。或者應用程序中存在異常的地方，比如死循環，或者其他寫程序時的邏輯錯誤導致。一般程序出錯會導致一個CPU被全部佔用，比如上述的20%佔用的原因就是一個交易程序長期佔用一個CPU全部時間片（系統共計5個CPU）。

區域2：反映網絡使用率的狀況。

Netwok；列出了網卡接口，KBPS即每秒鐘多少KB（千字節） I-Pack每秒鐘輸入的數據包個數， O-Pack 每秒鐘輸出的數據包個數  KB-In每秒鐘輸入的字節數 KB-Out每秒鐘輸出的字節數。

當我們發現網絡擁堵時（出現網卡傳輸失效的報錯，即網卡發送數據包失敗。或者網絡響應明顯變慢的時候，如果CPU沒有問題，那麼請檢查網絡流量）發現某一個網卡的KBPS持續大於四位數，甚至五位數時（這個值要是網卡千兆還是百兆而定）。就要看看這個網卡是什麼網卡，在處理什麼業務了。在命令行執行netstat –in 查看對應en*接口的ip地址，通過ip地址看看是帶官網卡還是生產服務網卡流量高。然後通過netstat –v en* 看看網卡的詳細工作狀態，出現了多少錯包，衝突包，crc校驗錯或者網絡重置過等信息。上述信息請詳細看netstat –v en*的輸出.如果出現大量crc，錯包的話，可能網線有問題或者接觸不良。

如果上述均正常，而網絡反應慢，則有可能是交換機擁堵。

網絡出現問題的可能原因：通過百兆的帶管網加載大量數據（以前出現過），大量隊列的長時間的ftp傳輸，或者網線，交換機問題等。

區域3：反映磁盤使用率的狀況。

Disk  Busy%磁盤繁忙的百分比，即磁盤能滿足的最大IOPS（每秒IO操作數）和當前IO數量的比率。其他的參數不再解釋。望文生義即可。

一般主要看磁盤的Busy%,當磁盤的Busy%持續大於85%時，即認爲磁盤相當繁忙，已經可能要出問題了。當然，自己知道已經確定要產生大量IO操作的內容則不必在意，等其完成即可。

出現問題的原因：應用服務器上面寫日誌進程或者查詢日誌的進程大量讀寫日誌，導致磁盤繁忙率高，或者其他程序頻繁讀寫磁盤導致。系統中hdisk0，hdisk1一般爲系統盤，內置SCSI磁盤的相對IOPS是較低的。很容易滿負荷運行。

區域4：反映進程信息的狀況。

Name：進程的名稱，即進程被執行時啓動的二進制文件的名稱。

PID，進程的ID，進程的ID在系統中唯一，是我們瞭解跟蹤進程信息重要數值。

跟蹤進程的CPU使用，磁盤IO讀寫，進程的內存和pagingspace佔用等等均需要使用。

CPU%進程佔用CPU時間的比率。

PgSp，進程佔用的pagingspace的空間大小。

Owner進程的屬主，即由哪個操作用戶用戶啓動了這個進程。

在topas中，默認是列出佔用cpu最高的前幾個的進程信息供參考，如果前面第一區域的的CPU使用率持續高，就要看看這裏是那個進程佔用了大量的CPU資源，看看是哪個用戶的進程，如果自己執行的，則殺掉或者找項目組解決即可。

區域5：反映內存頁面和換頁空間信息的狀況。

換頁空間即磁盤上的空間，在AIX操作系統中用來做內存空間使用。具體的理論就不再闡述了，詳細信息請參閱操作系統內容。磁盤空間的速度當然相比內存，慢了不止10倍。所以，只是內存頁面的一個暫時存放地，存放的還是那些長期不怎麼用到的內存頁面而已。如果paging大量出現，這時候就有麻煩了，說明：內存不夠用了！

該區域主要關注PageIn，PageOut如果這兩個數值均大於三位數，並且長期大於這個數值，在技術上叫做內存顛簸，即不停的把內存頁面換到磁盤空間上，又從磁盤空間把內存頁面讀進來，系統的內存使用效率變的極差，系統響應性能也變慢了。

這個信息也可以用vmstat來看，pi和po列即與這裏相對應。當然，如果只是有頁面出，或者只有頁面入，或者短時間的一些頁面換入換出，則沒有什麼問題，關注一下即可。

區域6：反映內存使用的信息。

Real，MB操作系統實際擁有的內存的總量，單位是MB。

%Comp，計算型內存佔用比率，%Noncomp非計算型內存佔用的比率。

%Client也爲非計算型內存，Noncomp包涵Client型內存，jfs文件系統使用的內存爲noncomp，爲了區分，jfs2和nfs使用的內存爲Client。

計算型內存就是進程實際使用的內存，例如我們寫程序的時候malloc內存，或者在排序中使用了堆棧，進程中變量數值都需要在內存中保存，這部分內存爲計算型內存（闡述不全面，僅供參考）。而操作系統在進行文件讀寫，需要的io緩衝區，或者我們在寫程序的時候，打開文件，讀寫文件，均在文件緩衝區進行。（裸設備例外，CCCC的數據庫採用RAC，數據的存儲全部使用裸設備，在數據庫服務器上，數據文件的緩衝在oracle的sga區的data buffer中（這個區域系統認爲是計算型內存），是不會佔用非計算內存的。）

導致內存出問題的可能原因很多。主要有：進程使用了更多的內存，例如，CCCC數據庫服務器大量的oracle連接使用了很多內存，或者數據庫中執行的某一個sql腳本或者存儲過程的執行需要大量的內存來完成其操作（特例庫中出現過這個情形，一個存儲過程的執行導致操作系統內存被耗盡，pg也隨之耗盡，操作系統自動執行PGSP_KILL,把該進程給幹掉了，我也是第一次知道aix系統還有這個功能，呵呵）。第二個主要的問題就是內存泄漏，內存泄漏最簡單的來說，就是申請了內存空間，使用後不再使用了，但是也沒有釋放。我們寫程序的時候malloc，卻沒有free。這就導致了嚴重的問題，隨着程序的執行，可用物理內存越來越少，最後就掛了，只好定期重啓應用來解決。

操作系統的內存換頁機制導致了程序中不用的內存頁面最後都跑到pg上面去了，換頁空間會持續增長的。因應用導致系統問題就是這麼產生的。

區域7反映的是換頁空間的使用率。

如果換頁空間的使用率長期增長，就說明系統內存不足，已經開始使用磁盤空間來緩衝內存了，如果PG使用率持續增長，或者大於50%，需要警惕（到50%在監控平臺已經是主要告警啦！），並馬上提交系統管理員分析內存增長原因。如果該數值持續增長，系統一定會掛掉的！