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(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%在監控平台已經是主要警示啦!),並馬上提交系統管理員分析記憶體增長原因。如果該數值持續增長,系統一定會掛掉的!