[[263688]]

1. 服務異常的處理流程

2. 負載

2.1 查看機器 cpu 的負載

top -b -n 1 |grep java|awk '{print "VIRT:"$5,"RES:"$6,"cpu:"$9"%","mem:"$10"%"}'

2.2 查找 cpu 占用率高的線程

top -p 25603 -H 
printf 0x%x 25842 
jstack 25603 | grep 0x64f2 
cat /proc/interrupts 

（1）CPU

（2）Memory

（3）IO

（4）Network

可以從以下幾個方面監控CPU的信息：

（1）中斷；

（2）上下文切換；

（3）可運行隊列；

（4）CPU 利用率。

3. 內存

3.1 系統內存

free 命令

[root@server ~]# free 
total used free shared buffers cached 
Mem: 3266180 3250000 10000 0 201000 3002000 
-/+ buffers/cache: 47000 3213000 
Swap: 2048276 80160 1968116 

這里的默認顯示單位是 kb。

各項指標解釋

• total:總計物理內存的大小。
• used:已使用多大。
• free:可用有多少。
• Shared:多個進程共享的內存總額。
• buffers: 磁盤緩存的大小。
• cache:磁盤緩存的大小。
• -/+ buffers/cached): used:已使用多大，free:可用有多少。
• 已用內存 = 系統used memory - buffers - cached
• （47000 = 3250000-201000-3002000）
• 可用內存 = 系統free memory + buffers + cached
• （3213000 = 10000+201000+3002000）

什么是buffer/cache？

• buffer 指 Linux 內存的：Buffer cache，緩沖區緩
• cache 指 Linux內存中的：Page cache，頁面緩存

page cache

page cache 主要用來作為文件系統上的文件數據的緩存來用，尤其是針對當進程對文件有 read／write 操作的時候。

如果你仔細想想的話，作為可以映射文件到內存的系統調用：mmap是不是很自然的也應該用到 page cache？在當前的系統實現里，page cache 也被作為其它文件類型的緩存設備來用，所以事實上 page cache 也負責了大部分的塊設備文件的緩存工作。

buffer cache

buffer cache 主要用來在系統對塊設備進行讀寫的時候，對塊進行數據緩存的系統來使用。這意味著某些對塊的操作會使用 buffer cache 進行緩存，比如我們在格式化文件系統的時候。

一般情況下兩個緩存系統是一起配合使用的，比如當我們對一個文件進行寫操作的時候，page cache 的內容會被改變，而 buffer cache 則可以用來將 page 標記為不同的緩沖區，并記錄是哪一個緩沖區被修改了。這樣，內核在后續執行臟數據的回寫（writeback）時，就不用將整個 page 寫回，而只需要寫回修改的部分即可。

在當前的內核中，page cache 是針對內存頁的緩存，說白了就是，如果有內存是以page進行分配管理的，都可以使用page cache作為其緩存來管理使用。

當然，不是所有的內存都是以頁（page）進行管理的，也有很多是針對塊（block）進行管理的，這部分內存使用如果要用到 cache 功能，則都集中到 buffer cache中來使用。（從這個角度出發，是不是buffer cache改名叫做block cache更好？）然而，也不是所有塊（block）都有固定長度，系統上塊的長度主要是根據所使用的塊設備決定的，而頁長度在X86 上無論是 32位還是 64位都是 4k。

3.2 進程內存

3.2.1 進程內存統計

/proc/[pid]/status

通過/proc//status可以查看進程的內存使用情況，包括虛擬內存大小（VmSize），物理內存大小（VmRSS），數據段大小（VmData），棧的大小（VmStk），代碼段的大小（VmExe），共享庫的代碼段大小（VmLib）等等。

Name: gedit /*進程的程序名*/ 
State: S (sleeping) /*進程的狀態信息,具體參見http://blog.chinaunix.net/u2/73528/showart_1106510.html*/ 
Tgid: 9744 /*線程組號*/ 
Pid: 9744 /*進程pid*/ 
PPid: 7672 /*父進程的pid*/ 
TracerPid: 0 /*跟蹤進程的pid*/ 
VmPeak: 60184 kB /*進程地址空間的大小*/ 
VmSize: 60180 kB /*進程虛擬地址空間的大小reserved_vm：進程在預留或特殊的內存間的物理頁*/ 
VmLck: 0 kB /*進程已經鎖住的物理內存的大小.鎖住的物理內存不能交換到硬盤*/ 
VmHWM: 18020 kB /*文件內存映射和匿名內存映射的大小*/ 
VmRSS: 18020 kB /*應用程序正在使用的物理內存的大小，就是用ps命令的參數rss的值 (rss)*/ 
VmData: 12240 kB /*程序數據段的大小（所占虛擬內存的大小），存放初始化了的數據*/ 
VmStk: 84 kB /*進程在用戶態的棧的大小*/ 
VmExe: 576 kB /*程序所擁有的可執行虛擬內存的大小,代碼段,不包括任務使用的庫 */ 
VmLib: 21072 kB /*被映像到任務的虛擬內存空間的庫的大小*/ 
VmPTE: 56 kB /*該進程的所有頁表的大小*/ 
Threads: 1 /*共享使用該信號描述符的任務的個數*/ 

3.2.2 JVM 內存分配

java內存組成介紹：堆(Heap)和非堆(Non-heap)內存

按照官方的說法：“Java 虛擬機具有一個堆，堆是運行時數據區域，所有類實例和數組的內存均從此處分配。堆是在 Java 虛擬機啟動時創建的。” “在JVM中堆之外的內存稱為非堆內存(Non-heap memory)”。

可以看出JVM主要管理兩種類型的內存：堆和非堆。

簡單來說堆就是Java代碼可及的內存，是留給開發人員使用的；非堆就是JVM留給自己用的。

所以方法區、JVM內部處理或優化所需的內存(如JIT編譯后的代碼緩存)、每個類結構(如運行時常數池、字段和方法數據)以及方法和構造方法 的代碼都在非堆內存中。

1. JVM 本身需要的內存，包括其加載的第三方庫以及這些庫分配的內存
2. NIO 的 DirectBuffer 是分配的 native memory
3. 內存映射文件，包括 JVM 加載的一些 JAR 和第三方庫，以及程序內部用到的。上面 pmap 輸出的內容里，有一些靜態文件所占用的大小不在 Java 的 heap 里，因此作為一個Web服務器，趕緊把靜態文件從這個Web服務器中人移開吧，放到nginx或者CDN里去吧。
4. JIT， JVM會將Class編譯成native代碼，這些內存也不會少，如果使用了Spring的AOP，CGLIB會生成更多的類，JIT的內存開銷也會隨之變大，而且Class本身JVM的GC會將其放到Perm Generation里去，很難被回收掉，面對這種情況，應該讓JVM使用ConcurrentMarkSweep GC，并啟用這個GC的相關參數允許將不使用的class從Perm Generation中移除， 參數配置：
5. -XX:+UseConcMarkSweepGC -X:+CMSPermGenSweepingEnabled -X:+CMSClassUnloadingEnabled，如果不需要移除而Perm Generation空間不夠，可以加大一點：-X:PermSize=256M -X:MaxPermSize=512M
6. JNI，一些JNI接口調用的native庫也會分配一些內存，如果遇到JNI庫的內存泄露，可以使用valgrind等內存泄露工具來檢測
7. 線程棧，每個線程都會有自己的棧空間，如果線程一多，這個的開銷就很明顯了
8. jmap/jstack 采樣，頻繁的采樣也會增加內存占用，如果你有服務器健康監控，記得這個頻率別太高，否則健康監控變成致病監控了。

1.方法區

也稱”***代” 、“非堆”，它用于存儲虛擬機加載的類信息、常量、靜態變量、是各個線程共享的內存區域。默認最小值為 16 MB，***值為 64 MB，可以通過-XX: PermSize 和 -XX: MaxPermSize 參數限制方法區的大小。

運行時常量池：是方法區的一部分，Class文件中除了有類的版本、字段、方法、接口等描述信息外，還有一項信息是常量池，用于存放編譯器生成的各種符號引用，這部分內容將在類加載后放到方法區的運行時常量池中。

2.虛擬機棧

描述的是java 方法執行的內存模型：每個方法被執行的時候 都會創建一個“棧幀”用于存儲局部變量表(包括參數)、操作棧、方法出口等信息。

每個方法被調用到執行完的過程，就對應著一個棧幀在虛擬機棧中從入棧到出棧的過程。聲明周期與線程相同，是線程私有的。

局部變量表存放了編譯器可知的各種基本數據類型(boolean、byte、char、short、int、float、long、double)、對象引用(引用指針，并非對象本身)，其中64位長度的long和double類型的數據會占用2個局部變量的空間，其余數據類型只占1個。

局部變量表所需的內存空間在編譯期間完成分配，當進入一個方法時，這個方法需要在棧幀中分配多大的局部變量是完全確定的，在運行期間棧幀不會改變局部變量表的大小空間。

3.本地方法棧

與虛擬機棧基本類似，區別在于虛擬機棧為虛擬機執行的java方法服務，而本地方法棧則是為Native方法服務。

4.堆

也叫做java 堆、GC堆是java虛擬機所管理的內存中***的一塊內存區域，也是被各個線程共享的內存區域，在JVM啟動時創建。

該內存區域存放了對象實例及數組(所有 new 的對象)。其大小通過 -Xms (最小值) 和 -Xmx (***值) 參數設置，-Xms為 JVM 啟動時申請的最小內存，默認為操作系統物理內存的 1/64 但小于 1G；

-Xmx 為 JVM 可申請的***內存，默認為物理內存的1/4但小于 1G，默認當空余堆內存小于 40% 時，JVM 會增大 Heap 到 -Xmx 指定的大小，可通過 -XX:MinHeapFreeRation= 來指定這個比列；

當空余堆內存大于70%時，JVM 會減小 heap 的大小到 -Xms 指定的大小，可通過XX:MaxHeapFreeRation= 來指定這個比列，對于運行系統，為避免在運行時頻繁調整 Heap 的大小，通常 -Xms 與 -Xmx 的值設成一樣。

由于現在收集器都是采用分代收集算法，堆被劃分為新生代和老年代。新生代主要存儲新創建的對象和尚未進入老年代的對象。老年代存儲經過多次新生代GC(Minor GC)任然存活的對象。

5.程序計數器

是最小的一塊內存區域，它的作用是當前線程所執行的字節碼的行號指示器，在虛擬機的模型里，字節碼解釋器工作時就是通過改變這個計數器的值來選取下一條需要執行的字節碼指令，分支、循環、異常處理、線程恢復等基礎功能都需要依賴計數器完成。

3.2.3 直接內存

直接內存并不是虛擬機內存的一部分，也不是Java虛擬機規范中定義的內存區域。jdk1.4中新加入的NIO，引入了通道與緩沖區的IO方式，它可以調用Native方法直接分配堆外內存，這個堆外內存就是本機內存，不會影響到堆內存的大小。

3.2.4 JVM 內存分析

查看 JVM 堆內存情況

jmap -heap [pid]

[root@server ~]$ jmap -heap 837 
Attaching to process ID 837, please wait... 
Debugger attached successfully. 
Server compiler detected. 
JVM version is 24.71-b01 
using thread-local object allocation. 
Parallel GC with 4 thread(s)//GC 方式 
Heap Configuration: //堆內存初始化配置 
MinHeapFreeRatio = 0 //對應jvm啟動參數-XX:MinHeapFreeRatio設置JVM堆最小空閑比率(default 40) 
MaxHeapFreeRatio = 100 //對應jvm啟動參數 -XX:MaxHeapFreeRatio設置JVM堆***空閑比率(default 70) 
MaxHeapSize = 2082471936 (1986.0MB) //對應jvm啟動參數-XX:MaxHeapSize=設置JVM堆的***大小 
NewSize = 1310720 (1.25MB)//對應jvm啟動參數-XX:NewSize=設置JVM堆的‘新生代’的默認大小 
MaxNewSize = 17592186044415 MB//對應jvm啟動參數-XX:MaxNewSize=設置JVM堆的‘新生代’的***大小 
OldSize = 5439488 (5.1875MB)//對應jvm啟動參數-XX:OldSize=<value>:設置JVM堆的‘老生代’的大小 
NewRatio = 2 //對應jvm啟動參數-XX:NewRatio=:‘新生代’和‘老生代’的大小比率 
SurvivorRatio = 8 //對應jvm啟動參數-XX:SurvivorRatio=設置年輕代中Eden區與Survivor區的大小比值 
PermSize = 21757952 (20.75MB) //對應jvm啟動參數-XX:PermSize=<value>:設置JVM堆的‘永生代’的初始大小 
MaxPermSize = 85983232 (82.0MB)//對應jvm啟動參數-XX:MaxPermSize=<value>:設置JVM堆的‘永生代’的***大小 
G1HeapRegionSize = 0 (0.0MB) 
Heap Usage://堆內存使用情況 
PS Young Generation 
Eden Space://Eden區內存分布 
capacity = 33030144 (31.5MB)//Eden區總容量 
used = 1524040 (1.4534378051757812MB) //Eden區已使用 
free = 31506104 (30.04656219482422MB) //Eden區剩余容量 
4.614088270399305% used //Eden區使用比率 
From Space: //其中一個Survivor區的內存分布 
capacity = 5242880 (5.0MB) 
used = 0 (0.0MB) 
free = 5242880 (5.0MB) 
0.0% used 
To Space: //另一個Survivor區的內存分布 
capacity = 5242880 (5.0MB) 
used = 0 (0.0MB) 
free = 5242880 (5.0MB) 
0.0% used 
PS Old Generation //當前的Old區內存分布 
capacity = 86507520 (82.5MB) 
used = 0 (0.0MB) 
free = 86507520 (82.5MB) 
0.0% used 
PS Perm Generation//當前的 “永生代” 內存分布 
capacity = 22020096 (21.0MB) 
used = 2496528 (2.3808746337890625MB) 
free = 19523568 (18.619125366210938MB) 
11.337498256138392% used 
670 interned Strings occupying 43720 bytes. 

關于這里的幾個generation網上資料一大把就不細說了，這里算一下求和可以得知前者總共給Java環境分配了644M的內存，而ps輸出的VSZ和RSS分別是7.4G和2.9G，這到底是怎么回事呢？

前面jmap輸出的內容里，MaxHeapSize 是在命令行上配的，-Xmx4096m，這個java程序可以用到的***堆內存。

VSZ是指已分配的線性空間大小，這個大小通常并不等于程序實際用到的內存大小，產生這個的可能性很多，比如內存映射，共享的動態庫，或者向系統申請了更多的堆，都會擴展線性空間大小，要查看一個進程有哪些內存映射，可以使用 pmap 命令來查看：

pmap -x [pid]

[root@server ~]$ pmap -x 837 
837: java 
Address Kbytes RSS Dirty Mode Mapping 
0000000040000000 36 4 0 r-x-- java 
0000000040108000 8 8 8 rwx-- java 
00000000418c9000 13676 13676 13676 rwx-- [ anon ] 
00000006fae00000 83968 83968 83968 rwx-- [ anon ] 
0000000700000000 527168 451636 451636 rwx-- [ anon ] 
00000007202d0000 127040 0 0 ----- [ anon ] 
... 
... 
00007f55ee124000 4 4 0 r-xs- az.png 
00007fff017ff000 4 4 0 r-x-- [ anon ] 
ffffffffff600000 4 0 0 r-x-- [ anon ] 
---------------- ------ ------ ------ 
total kB 7796020 3037264 3023928 

這里可以看到很多anon，這些表示這塊內存是由mmap分配的。

RSZ是Resident Set Size，常駐內存大小，即進程實際占用的物理內存大小， 在現在這個例子當中，RSZ和實際堆內存占用差了2.3G，這2.3G的內存組成分別為：

查看 JVM 堆各個分區的內存情況

jstat -gcutil [pid]

[root@server ~]$ jstat -gcutil 837 1000 20 
S0 S1 E O P YGC YGCT FGC FGCT GCT 
0.00 80.43 24.62 87.44 98.29 7101 119.652 40 19.719 139.371 
0.00 80.43 33.14 87.44 98.29 7101 119.652 40 19.719 139.371 

分析 JVM 堆內存中的對象

查看存活的對象統計

jmap -histo:live [pid]

dump 內存

jmap -dump:format=b,file=heapDump [pid]

然后用jhat命令可以參看

jhat -port 5000 heapDump

在瀏覽器中訪問：http://localhost:5000/ 查看詳細信息

4. 服務指標

4.1 響應時間(RT)

響應時間是指系統對請求作出響應的時間。直觀上看，這個指標與人對軟件性能的主觀感受是非常一致的，因為它完整地記錄了整個計算機系統處理請求的時間。

由于一個系統通常會提供許多功能，而不同功能的處理邏輯也千差萬別，因而不同功能的響應時間也不盡相同，甚至同一功能在不同輸入數據的情況下響應時間也不相同。

所以，在討論一個系統的響應時間時，人們通常是指該系統所有功能的平均時間或者所有功能的***響應時間。

當然，往往也需要對每個或每組功能討論其平均響應時間和***響應時間。

對于單機的沒有并發操作的應用系統而言，人們普遍認為響應時間是一個合理且準確的性能指標。需要指出的是，響應時間的絕對值并不能直接反映軟件的性能的高低，軟件性能的高低實際上取決于用戶對該響應時間的接受程度。

對于一個游戲軟件來說，響應時間小于100毫秒應該是不錯的，響應時間在1秒左右可能屬于勉強可以接受，如果響應時間達到3秒就完全難以接受了。

而對于編譯系統來說，完整編譯一個較大規模軟件的源代碼可能需要幾十分鐘甚至更長時間，但這些響應時間對于用戶來說都是可以接受的。

4.2 吞吐量(Throughput)

吞吐量是指系統在單位時間內處理請求的數量。對于無并發的應用系統而言，吞吐量與響應時間成嚴格的反比關系，實際上此時吞吐量就是響應時間的倒數。

前面已經說過，對于單用戶的系統，響應時間（或者系統響應時間和應用延遲時間）可以很好地度量系統的性能，但對于并發系統，通常需要用吞吐量作為性能指標。

對于一個多用戶的系統，如果只有一個用戶使用時系統的平均響應時間是t，當有你n個用戶使用時，每個用戶看到的響應時間通常并不是n×t，而往往比n×t小很多（當然，在某些特殊情況下也可能比n×t大，甚至大很多）。

這是因為處理每個請求需要用到很多資源，由于每個請求的處理過程中有許多不走難以并發執行，這導致在具體的一個時間點，所占資源往往并不多。也就是說在處理單個請求時，在每個時間點都可能有許多資源被閑置，當處理多個請求時，如果資源配置合理，每個用戶看到的平均響應時間并不隨用戶數的增加而線性增加。

實際上，不同系統的平均響應時間隨用戶數增加而增長的速度也不大相同，這也是采用吞吐量來度量并發系統的性能的主要原因。

一般而言，吞吐量是一個比較通用的指標，兩個具有不同用戶數和用戶使用模式的系統，如果其***吞吐量基本一致，則可以判斷兩個系統的處理能力基本一致。

4.3 并發用戶數

并發用戶數是指系統可以同時承載的正常使用系統功能的用戶的數量。與吞吐量相比，并發用戶數是一個更直觀但也更籠統的性能指標。

實際上，并發用戶數是一個非常不準確的指標，因為用戶不同的使用模式會導致不同用戶在單位時間發出不同數量的請求。

一網站系統為例，假設用戶只有注冊后才能使用，但注冊用戶并不是每時每刻都在使用該網站，因此具體一個時刻只有部分注冊用戶同時在線，在線用戶就在瀏覽網站時會花很多時間閱讀網站上的信息，因而具體一個時刻只有部分在線用戶同時向系統發出請求。

這樣，對于網站系統我們會有三個關于用戶數的統計數字：注冊用戶數、在線用戶數和同時發請求用戶數。由于注冊用戶可能長時間不登陸網站，使用注冊用戶數作為性能指標會造成很大的誤差。而在線用戶數和同事發請求用戶數都可以作為性能指標。

相比而言，以在線用戶作為性能指標更直觀些，而以同時發請求用戶數作為性能指標更準確些。

4.4 QPS每秒查詢率(Query Per Second)

每秒查詢率QPS是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準，在因特網上，作為域名系統服務器的機器的性能經常用每秒查詢率來衡量。對應fetches/sec，即每秒的響應請求數，也即是***吞吐能力。

從以上概念來看吞吐量和響應時間是衡量系統性能的重要指標，QPS雖然和吞吐量的計量單位不同，但應該是成正比的，任何一個指標都可以含量服務器的并行處理能力。當然Throughput更關心數據量，QPS更關心處理筆數。

4.5 CPU利用率

CPU Load Average < CPU個數 核數 0.7

Context Switch Rate

就是Process（Thread）的切換，如果切換過多，會讓CPU忙于切換，也會導致影響吞吐量。

《高性能服務器架構 》這篇文章的第2節就是說的是這個問題的。

究竟多少算合適？google 了一大圈，沒有一個確切的解釋。

Context Switch大體上由兩個部分組成：中斷和進程(包括線程)切換，一次中斷（Interrupt）會引起一次切換，進程（線程）的創建、激活之類的也會引起一次切換。CS的值也和TPS（Transaction Per Second）相關的，假設每次調用會引起N次CS，那么就可以得出

Context Switch Rate = Interrupt Rate + TPS* N

CSR減掉IR，就是進程/線程的切換，假如主進程收到請求交給線程處理，線程處理完畢歸還給主進程，這里就是2次切換。

也可以用CSR、IR、TPS的值代入公式中，得出每次事物導致的切換數。因此，要降低CSR，就必須在每個TPS引起的切換上下功夫，只有N這個值降下去，CSR就能降低，理想情況下N=0，但是無論如何如果N >= 4，則要好好檢查檢查。另外網上說的CSR<5000，我認為標準不該如此單一。

這三個指標在 LoadRunner 中可以監控到；另外，在 linux 中，也可以用 vmstat 查看r（Load Arerage），in（Interrupt）和cs（Context Switch）

5. 工具

uptime

dmesg

top

查看進程活動狀態以及一些系統狀況

vmstat

查看系統狀態、硬件和系統信息等

iostat

查看CPU 負載，硬盤狀況

sar

綜合工具，查看系統狀況

mpstat

查看多處理器狀況

netstat

查看網絡狀況

iptraf

實時網絡狀況監測

tcpdump

抓取網絡數據包，詳細分析

mpstat

查看多處理器狀況

tcptrace

數據包分析工具

netperf

網絡帶寬工具

dstat

綜合工具，綜合了 vmstat, iostat, ifstat, netstat 等多個信息