java性能監控經常使用的幾個命令

     找到性能問題的第一步是監控應用的行爲，經過監控提供的線索，咱們能夠將性能問題進行歸類並分析。

     一、CPU使用率：大多數操做系統的CPU使用率分爲用戶態CPU使用率和系統態CPU使用率。用戶態CPU使用率是指執行應用程序代碼的時間佔總CPU時間的百分比，相比而言，系統態CPU使用率是指應用執行操做系統調用的時間佔總CPU時間的百分比。系統態CPU使用率高意味着共享資源有競爭或者I/O設備之間有大量的交互。理想狀況下，應用達到最高性能和擴展時，它的系統態CPU使用率爲0%，因此提升應用性能和擴展性的一個目標是儘量下降系統態CPU使用率。

        CPU停滯一般會浪費幾百個時鐘週期，所以提升計算密集型應用性能的策略是減小停滯或者改善CPU高速緩存使用率，從而減小CPU在等待內存數據時浪費的時鐘週期。

         Linux命令行監控CPU使用率的有vmstat或者top（或者htop，須要自行安裝，但查看效果更好）：

vmstat  採集間隔(秒)   採集次數

當一直監控時，能夠省去採集次數，即 vmstat 2，每隔2秒採集一次，一直持續。

命令介紹完畢，如今開始實戰講解每一個參數的意思，後面還會使用到：

r        表示運行隊列的長度，值是運行隊列中輕量級進程的實際數量，即當內核線程已經準備好運行只是尚未可用的處理器執行時，運行隊列就會有值。

b         表示阻塞隊列，當內核線程等待諸如I/O，內存頁等資源時，阻塞隊列就會有值。

swpd    虛擬內存已使用的大小，若是大於0，表示你的機器物理內存不足了，若是不是程序內存泄露的緣由，那麼你該升級內存了或者把耗內存的任務遷移到其餘機器。

free   空閒的物理內存的大小。

buff   Linux/Unix系統是用來存儲，目錄裏面有什麼內容，權限等的緩存。

cache cache直接用來記憶咱們打開的文件,給文件作緩衝(這裏是Linux/Unix的聰明之處，把空閒的物理內存的一部分拿來作文件和目錄的緩存，是爲了提升 程序執行的性能，當程序使用內存時，buffer/cached會很快地被使用。)

si  每秒從磁盤讀入虛擬內存的大小，若是這個值大於0，表示物理內存不夠用或者內存泄露了，要查找耗內存進程解決掉。個人機器內存充裕，一切正常。

so  每秒虛擬內存寫入磁盤的大小，若是這個值大於0，同上。

bi  塊設備每秒接收的塊數量，這裏的塊設備是指系統上全部的磁盤和其餘塊設備，默認塊大小是1024byte，我本機上沒什麼IO操做，因此一直是0，可是我曾在處理拷貝大量數據(2-3T)的機器上看過能夠達到140000/s，磁盤寫入速度差很少140M每秒

bo 塊設備每秒發送的塊數量，例如咱們讀取文件，bo就要大於0。bi和bo通常都要接近0，否則就是IO過於頻繁，須要調整。

in 每秒CPU的中斷次數，包括時間中斷

cs 每秒上下文切換次數，例如咱們調用系統函數，就要進行上下文切換，線程的切換，也要進程上下文切換，這個值要越小越好，太大了，要考慮調低線程或者進程的數目,例如在apache和nginx這種web服務器中，咱們通常作性能測試時會進行幾千併發甚至幾萬併發的測試，選擇web服務器的進程能夠由進程或者線程的峯值一直下調，壓測，直到cs到一個比較小的值，這個進程和線程數就是比較合適的值了。系統調用也是，每次調用系統函數，咱們的代碼就會進入內核空間，致使上下文切換，這個是很耗資源，也要儘可能避免頻繁調用系統函數。上下文切換次數過多表示你的CPU大部分浪費在上下文切換，致使CPU幹正經事的時間少了，CPU沒有充分利用，是不可取的。

us 用戶態CPU使用率，我曾經在一個作加密解密很頻繁的服務器上，能夠看到us接近100,r運行隊列達到80(機器在作壓力測試，性能表現不佳)。

sy 系統態CPU使用率，若是過高，表示系統調用時間長，例如是IO操做頻繁。

id  空閒態 CPU使用率，通常來講，id + us + sy = 100,通常我認爲id是空閒CPU使用率，us是用戶CPU使用率，sy是系統CPU使用率。

wa 等待IO CPU使用率。

vmstat和top不同的地方就是vmstat統計的是全部的cpu，而top是單獨統計每一個cpu的。

那麼在監控時查看us、sy、id就能夠監控到CPU的使用狀況了。另外經過top和java的jstack能夠找到佔用CPU太高的線程以及致使線程佔用CPU太高的方法（參見轉載的另一篇文章http://my.oschina.net/u/128568/blog/198345）。

二、CPU調度程序運行隊列：除CPU使用率以外，監控CPU調度程序運行隊列對於分辨系統是否滿負荷也有重要意義。

       解決運行隊列長有2中辦法：一種是增長CPU以分擔負載或減小處理器的負載量，另外一種是分析應用，改進CPU使用率。

     一樣是使用vmstat，查看第一項的輸出，就是  r .    若是在很長一段時間內，運行隊列的長度一直都超過虛擬處理器個數的一倍，就須要關注了。只是暫時還不須要採起行動。若是長度達到虛擬處理器個數的3-4倍或更高，此時系統的響應將會很是遲緩，就須要當即引發注意或採起行動。

三、內存使用率：當頁面調度或者頁面交換、加鎖、線程遷移中的讓步式和搶佔式上下文切換都會致使內存使用率很高，而且還伴隨着大量的swap（頁面交換）發生。

     爲何內存使用率高而且大量交換髮生時就是性能差的表現，而單獨的內存使用率高是不能斷定性能差的呢?當訪問應用中被置換出去的部分時（置換出去的部分是比較少使用的），就必須將它從磁盤置換進內存，而這種置換活動會對應用的響應性和吞吐量形成很大影響。好比JVM垃圾回收，垃圾收集器爲了回收不可達對象所佔用的空間，就須要訪問大量內存，若是java堆的一部分被置換出去，就必須裝進來，而且垃圾收集是會發生Stop-The-World，這樣會引發JVM長時間的停頓。

      如上所說，使用vmstat，查看free、si、so三列來斷定內存使用情況。當系統空閒內存恨少時，free列會保持在一個比較穩定的值，由於si和so的置換速度已經幾乎同樣快。

四、監控鎖競爭：掛起和喚醒線程會致使操做系統的讓步式上下文切換。所以鎖競爭嚴重的應用會表現出大量的讓步式上下文切換。讓步式上下文切換耗費的時鐘週期代價很是高，一般高達80000個時鐘週期。

       能夠遵循的通常性準則，對於任何java應用來講，若是讓步式上下文切換佔去它3%-5%或者更多時鐘週期，說明遇到了鎖競爭。Linux上可使用sysstat包中的pidstat監控鎖競爭。pidstat -w 輸出結果中的cswch/s是讓步式上下文切換。注意它統計的全部處理器的讓步式上下文切換。

計算公式： (讓步式上下文切換 / 虛擬處理器數目)  *  80000   /  該處理器的時鐘週期

hadoop@slave1:~$ pidstat -w -I -p 9391 5
Linux 3.2.0-23-generic (slave1) 	03/16/2014 	_x86_64_	(1 CPU)
03:14:36 PM       PID   cswch/s nvcswch/s  Command
03:14:41 PM      1034      3645      322    java
03:14:46 PM      1034      3512      292    java
03:14:51 PM      1034      3499      310     java

好比機器是處理器個數是2（查看命令，grep processor /proc/cpuinfo | wc -l），3GHZ的CPU，計算以下：

（3500/2）* 80000 / 3 000 000 000 = 4.7%。根據通常準則（3%~5%），說明java應用正面臨競爭。

五、監控搶佔式上下文切換：讓步式上下文切換是指執行線程主動釋放鎖，搶佔式上下文切換是指線程由於分配的時間片用盡而被迫放棄CPU或者被其餘優先級更高的線程所搶佔。一樣如上面第四個所言，cswch/s是每秒的讓步式上下文切換，nvccswch/s是搶佔式上下文切換。

六、監控網絡IO：在分佈式java應用中，網絡也成爲性能的一個重要因素。監控網絡主要是監控網卡接收和發送數據的狀況，所以不能使用netstat。採用nicstat，安裝參考http://xuclv.blog.51cto.com/5503169/1157208

列名的含義以下：

Int  網絡接口設備名
rKB/s, InKB   每秒讀取的KB數
wKB/s, OutKB   每秒寫入的KB數
rPk/s, InSeg, InDG  每秒讀取的包數
wPk/s, OutSeg, OutDG  每秒寫入的包數
rAvs  每秒讀取的平均字節
wAvs  每秒寫入的平均字節
%Util 網絡接口使用率 
Sat   飽和度

七、監控磁盤IO:磁盤IO使用systat保重的iostat來監控。

     監控IO的意義何在呢，主要是因爲磁盤的讀寫速度發展徹底跟不上CPU的發展速度，不少時候不是CPU慢，而是硬盤讀寫數據太慢。那麼有哪些辦法改進磁盤的IO使用率呢：

     1）、更快的存儲設備。舉例來講，在hadoop生態系統中，hbase是使用hdfs做爲底層存儲，而hbase的高效是以大量的寫入和讀取來換取的，此時磁盤讀寫就是一個很大的瓶頸，那麼多增長几個磁盤（可同時想多個磁盤進行IO讀寫），或者使用SSD來緩存熱數據，冷數據放在通常的磁盤中（參考facebook的HBase優化案例：http://www.infoq.com/cn/articles/hbase-casestudy-facebook-messages/  ）。   

     2)、文件系統擴展到多個磁盤。如上一條所說，hadoop其中一個優化就是容許配置多個磁盤做爲hdfs的寫入和讀取，這麼作的緣由就是一個磁盤的尋道速度有限，那麼多幾個磁盤能夠同時尋道，速度天然就增快。

     3)、操做系統調優使得能夠緩存大量的文件系統數據結構。

任何減小磁盤活動的策略都有幫助，好比java中使用緩衝流進行讀寫，或者對於重複讀取同一文件的，能夠一次讀取這個文件，緩存後便於後面的讀取，等等。

命令展現了對每一個盤的io統計。其中%system表示系統態CPU使用率，%util下的值顯示的每一個盤的io使用狀況。

這些命令本身也不怎麼熟悉，歡迎有更多經驗的人分享本身心得，歡迎拍磚，後續還有更多的有關性能方面的博客。