系統性能指標查看方法-概述

1、CPU使用率

一、大多數的操做系統的CPU使用率分爲用戶態CPU使用率和系統態CPU使用率。

用戶態CPU使用率是指執行應用程序代碼的時間佔總CPU時間的百分比。

系統態CPU使用率是指應用執行操做系統調用的時間佔總CPU時間的百分比。系統態CPU使用率高意味着共享資源有競爭或者I/O設備之間有大量的交互。

既然本來用於執行操做系統內核調用的CPU週期也能夠用來執行應用代碼，因此理想狀況下，應用達到最高性能和擴展性時，它的系統態CPU使用率爲0%，因此提升應用性能和擴展性的一個目標是儘量下降系統態CPU使用率。

二、對於計算密集型應用來講，不只要監控用戶態和系統態CPU使用率，還要進一步監控每時鐘指令數（Instructions Per Clock，IPC）或每指令時鐘週期（Cycles Per Instruction，CPI）等指標。這兩個指標對於計算密集型應用來講很重要，由於現代操做系統自帶的CPU使用率監控工具只能報告CPU使用率，而沒有CPU執行指令佔用CPU時鐘週期的百分比，這意味着，即使CPU在等待着內存中的數據，操做系統工具仍然會報告CPU繁忙。這種狀況一般被稱爲停滯。當CPU執行指令所用的操做數據不在寄存器或者緩存中時，就會發生停滯，因爲指令執行前必須等待數據從內存中裝入CPU寄存器，因此一旦發生停滯，就會浪費時鐘週期。CPU停滯一般會等待好幾百個時鐘週期，所以提升計算密集型應用性能的策略就是減小停滯或者改善CPU高速緩存使用率，從而減小CPU在等待內存數據時浪費的時鐘週期

2、CPU調度程序運行隊列

一、監控CPU調度程序運行隊列對於分辨系統是否滿負荷也有重要意義。運行隊列中就是那些已準備好運行、正等待可用CPU的輕量級進程。若是準備運行的輕量級進程數超過系統所能處理的上限，運行隊列就會很長。運行隊列長代表系統負載可能飽和。系統運行隊列長度等於虛擬機處理器的個數時，用戶不會明顯感受到性能降低。此處虛擬處理器的個數就是系統硬件線程的個數，也是Java API Runtime.availableProcessors()的返回值。當運行隊列長度達到虛擬處理的4倍或者更多時，系統的響應就很是遲緩了。

二、通常性的指導原則是：若是在很長一段時間裏，運行隊列的長度一直都超過虛擬處理器個數的1倍，就須要關注了，只是暫時還不須要馬上採起行動。若是在很長一段時間裏，運行隊列長度達到虛擬處理器個數的3~4倍或更高，則須要馬上引發注意和採起行動。

三、解決運行隊列長有兩種方法：一種是增長CPU以分擔負載或減小處理器的負載量；另外一種方法是分析系統中運行的應用，改進CPU使用率。研究能夠減小應用運行所需CPU週期的方法。Java程序員能夠經過更有效的算法和數據結構來實現更好的性能。經過性能分析能夠找出哪些算法和數據結構值得關注。

3、內存使用率

一、除了CPU使用率，還須要監控系統內存相關的屬性，例如頁面調度或頁面交換、加鎖、線程遷移中德讓步式和搶佔式上下文切換。

二、系統在進行頁面交換或者使用虛擬內存時，Java應用或JVM會表現出明顯的性能問題。當應用運行所需的內存超過可用物理內存時，就會發生頁面交換。爲了應對這種可能出現的狀況，一般要爲系統配置swap空間。swap空間通常會在一個獨立的磁盤分區上。當應用耗盡內存時，操做系統會將應用的一部分置換到磁盤上的swap空間。一般是應用中最少運行的部分，以避免影響整個應用或者應用最忙的那部分。當訪問應用中被置換出去的部分時，就必須將它從磁盤置換進內存，而這種置換活動會對應用的響應性和吞吐量形成很大影響。

三、JVM垃圾收集器在系統頁面交換時的性能也不好，這是因爲垃圾收集器爲了回收不可達對象所佔用的空間，須要訪問大量的內存。若是Java堆得一部分被置換出去，就必須先置換進內存以便垃圾收集器掃描存活對象，這會增長垃圾收集的持續時間。垃圾收集是一種Stop-The-World（時空停滯）操做，即中止全部正在運行的應用線程，若是此時系統正在進行頁面交換，則會引發JVM長時間的停頓。

四、若是發現垃圾收集時間變長，系統有可能正在進行也沒交換，爲了驗證這一點，你必須監控系統的頁面交換。

4、網絡I/O使用率

一、分佈式Java應用的性能和擴展性受限於網絡帶寬或網絡I/O的性能。若是發送到系統網絡接口硬件的消息量超過了它的處理能力。，消息就會進入操做系統的緩衝區，這會致使應用延遲。此外網絡上發生的其餘情況也會致使延遲。

二、應用性能改進的考慮，單次讀寫數據量小而網絡讀寫量大的應用會消耗大量的系統態CPU，產生大量的系統調用。對於這類應用，減小系統態CPU的策略是減小網絡讀寫的系統調用。此外，使用非阻塞的java Nio而不是阻塞的java.net.Socket，減小處理請求和發送響應的線程數，也能夠改善應用性能。從非阻塞socket中讀取數據的策略是，應用在每次讀請求時儘量多的讀取數據，一樣，當往socket中寫數據時，每一個寫調用應該儘量多的寫。

5、磁盤I/O使用率

一、對於有磁盤操做的應用來講，查找性能問題，就應該監控磁盤I/O。一些應用的核心功能須要大量使用磁盤，例如數據庫，幾乎全部的應用都會用日誌記錄重要的狀態信息或者事件發生時的應用行爲，磁盤I/O使用率是理解應用磁盤使用狀況最有用的監控數據。

二、從應用的角度看，任何減小磁盤活動的策略都有幫助，例如使用帶緩存的輸入輸出流以減小度、寫操做次數，或在應用中集成緩存的數據結構以減小或消除磁盤交互。緩衝流減小了調用操做系統調用的次數從而下降系統態CPU使用率，雖然這不會改善磁盤I/O性能，但可使更多CPU週期用於應用的其餘部分或者其餘運行的應用。JDK提供了緩衝數據結構，也容易使用，如java.io.BufferedInputStream和java.io.BufferedOutputStream。

三、關於磁盤性能，有一個常常被忽略的方法，就是檢查磁盤緩存是否開啓，有一些系統將磁盤緩存設置爲禁用。開啓磁盤緩存能夠改善嚴重依賴磁盤I/O的應用的性能。然而，若是發現系統默認設置爲禁用磁盤緩存，你應該加以注意，由於一旦開啓磁盤緩存，意外的電源故障可能會形成數據損壞。

6、查看指標的方法：

一、Windows：http://www.javashuo.com/article/p-kulxogbv-cq.html

二、Linux：http://www.javashuo.com/article/p-endddgio-bo.html