用戶響應時間=服務器響應時間+網絡時間
系統性能分析思路
（1）整體系統CPU利用率
（2）內存利用率
（3）磁盤I/O的利用率和延遲
（4）網絡利用率
cpu
CPU：top、vmstat、uptime、sar
一般我們期望會期望系統平均可用的CPU不少於20%
JVM自帶監控命令：jstat、jmap、Jvisualvm、JConsole
Mysql監控工具：Spolight、Monyog、及命令行工具
內存
total used free buffers cached
Mem 物理內存總量 使用的物理內存總量 空閑的物理內存總量 用作內核緩存的內存量 緩存的交換區總量
swap 交換區總量 使用的交換區總量 空閑交換區總量
可用物理內存=Mem（free+buffers+cached）
當物理內存不夠時，會使用swap分區，所以性能測試過程中需要關注swap和mem的使用情況。物理內存不夠，大量的內存置換到swap空間，可能導致CPU和I/O的瓶頸。
I/O
I/O比較頻繁（讀或者寫）的時候，如果I/O得不到滿足會導致應用的阻塞。
需要考慮I/O的TPS、平均I/O數據、平均隊列長度、平均服務時間、平均等待時間、IO利用率（磁盤Busy Time%）等指標
總結
很多時候，這些因素彼此之間是相互依賴的，任何一個處於高負載狀態，都可能導致其他資源受到影響，如：
（1）大量的網絡吞吐量導致占用CPU的資源增大，此時系統要分出部分資源進行軟件終端的處理
（2）大量的CPU開銷會嘗試更多的內存使用
理解並分析當前系統的特點很重要，多數系統對應的應用類型分為以下兩種：
（1）IO范疇
大量數據處理的過程，不對CPU及網絡發起更多請求。如數據庫軟件（mysql、Oracle）
（2）CPU范疇
批量處理CPU請求及數學計算的過程。如：webserver、mailserver等。
瓶頸分析
CPU定位分析
CPU利用率大於50%是，需要注意了；大於70%，需要密切關注；高於90%，情況比較嚴重了。
監控命令：vmstat、sar、dstat、mpstat、top、ps
| 類型 | 度量方法 | 衡量標准 |
| 使用情況 | 1、vmstat 統計1-%id的計數 2、sar -u 統計1-%idle的計數 3、dstat 統計1-%idl的計數 4、mpstat -P ALL 統計%idle的計數 5、ps 統計CPU的計數 |
注意>=50% 告警>=70% 嚴重>=90% |
| 滿載 | 6、vmstat的r計數器> cpu邏輯顆數 7、sar -q ,“runq-sz”>cpu邏輯顆數 8、dstat -q ,“run”>cpu邏輯顆數 |
運行隊列大於1時，證明已經有一定的負載了，不過這個計數也不絕對，需要進一步分期其他的資源情況來斷定是否CPU已經滿負荷運作 |
| 錯誤 | 9、perf工具捕獲處理器的錯誤信息，需處理器支持 | 安裝perf：yum install perf* 需處理器支持 |
內存定位分析
監控命令：vmstat、sar、dstat、free、top、ps等
| 類型 | 度量方法 |
衡量標注 |
| 使用情況 | 1、free 查看使用情況 2、vmstat 3、sar -r 4、ps |
注意>=50% 告警>=70% 嚴重>=80% |
| 滿載 | 5、vmstat的si/so比例輔助swapd和free利用 6、sar -W 查看次缺頁數 7、查看內核日志有誤OOM機制kill進程 8、dmesg | grep killed |
1、so數值大，且swapd已經占比很高，內存肯定已經飽和 2、sar命令次缺頁多意味已經在不定地和swap打交道，證明內存已經飽和 3、但內存不夠用會出發內核的OOM機制 |
| 錯誤 | 9、查看內核有無physical failures 10、通過工具如valgrind等進行檢查 |
有計數 |
網絡定位分析
監控命令：sar、ifconfig、netstat，以及查看net的dev速率，通過查看發現收發包的吞吐率達到網卡的最大上限，網絡數據報文有因為這類原因而引起的丟包、阻塞等現象都證明當前網絡可能存在瓶頸。在進行性能測試是為了減小網絡的影響，一般我們都在局域網中進行測試執行。
| 類型 | 度量方法 | 衡量標准 |
| 使用情況 | 1、sar -n DEV 的收發計數大於網卡上限 2、ifconfig RX/TX寬帶超過網卡上限 3、cat /proc/net/dev的速率超過上限 4、nicstat的util基本滿負荷 |
1、收發包的吞吐速率達到網卡上限 2、有延遲 3、有丟包 4、有阻塞 |
| 滿載 | 5、ifconfig dropped 有計數 6、netstat -s "segments retransmited"有計數 7、sar -n EDEV，rxdrop/s txdrop/s有計數 |
統計的丟包有計數證明已經滿了 |
| 錯誤 | 8、ifconfig，“errors” 9、netstat -i，RX-ERR TX-ERR 10 sar -n EDEV，rxerr/s txerr/s 11、ip -s link， “errors” |
錯誤有計數 |
IO定位分析
監控命令：sar、iostat、iotop
| 類型 | 度量方法 | 衡量標准 |
| 使用情況 | 1、iostat -xz，“%util” 2、sar -d，“%util” 3、iotop的利用率很高 4、cat /proc/pid/sched | grep iowait |
注意>=40% 告警>=60% 嚴重>=80% |
| 滿載 | 5、iostat -xnz，“avgqu-sz ”>1 6、iostat await>70 |
IO已經有滿載嫌疑 |
| 錯誤 | 7、dmseg 查看io錯誤 8、smartctl /dev/sda |
有信息 |
linux系統性能分析思路和實踐
系統負載監控分析實踐
可以通過uptime、top、w等命令分析
uptime
系統時間 up:主機運行時間 當前登錄用戶數 平均負載：過去1分鍾、5分鍾、15分鍾
（1）運行時間越長，系統越穩定
（2）當前用戶數，用w命令可以更詳細
（3）系統的平均負載只在特定時間間隔內運行隊列中的平均進程數。
一般建議每個CPU內核平均負載不大於0.8；若大於1~3之間，如果系統其他資源都很正常，可接受；若>5，則系統性能有問題
uptime是從文件/proc/loadavg文件里面讀取的。統計過去1分鍾、5分鍾、15分鍾平均負載：
[dcai@localhost ~]$ uptime | awk '{print $(NF-2)}'
0.00,
[dcai@localhost ~]$ uptime | awk '{print $(NF-1)}'
0.02,
[dcai@localhost ~]$ uptime | awk '{print $NF}'
0.12
系統監控分析實戰
top之外，還有htop、dstat、nmon、glances等
top
1、第一行：uptime一樣
2、第二行：運行狀態信息
運行、睡眠、中斷、僵死
3、第三行：CPU信息
us：用戶占用CPU百分比
sy：系統占用CPU百分比
ni：優先級(用戶進程空間內改變過優先級的進程占用CPU百分比)，范圍-20（最低優先級）~19（最高優先級）
id：空閑CPU百分比
wa：等待輸入輸出的CPU時間百分比
hi：硬中斷占用的CPU百分比
si：軟中斷占用的百分比
我們比較關注：us、sy、id、wa、hi、si這六個數值
（1）按下鍵盤1，可以顯示每個邏輯CPU的使用情況
（2）id持續過低時，系統迫切需要解決CPU資源問題
（3）wa使用率過高，需要考慮IO性能是否有瓶頸，可以用iostat，sar等命令進一步分析
（3）hi使用率過高，可以分析文件 /proc/interrupts、/proc/irq/pid/smp_affinity、服務irqbalance是否配置、以及CPU的頻率設置，通過這些可以幫系統大賽優化系統的硬中斷
（4）si：內核通過一種軟件的方法（可延遲函數）來模擬硬件的中斷模式，通常叫軟中斷。常見的軟中斷都和網絡有關，長時間的寫日志也可能產生軟中斷。
系統有個進程ksoftirqd來處理軟中斷，每個CPU都有自己對應的ksoftirqd/n（n為CPU邏輯ID）。但網絡出現阻塞的時候，ksoftirqd會出現瓶頸，此時可通過ps命令查看ps aux | grep ksoftirqd
（5）CPU利用率=1-%id
4、第四行+第五行：內存使用情況
buffer和cache的作用是縮短IO系統調用的時間。如果頻繁地訪問文件都能被命中，很明顯會比讀取磁盤調用快，磁盤的IO必定會減小。cache的命中率很關鍵，如果不能命中，對cache而言是極大的浪費，此時應考慮drop cache並提升相應的cache命中率。
5、第六行：進程信息
進程號（PID）、進程所有者（USER）、進程優先級（nice值、NI）、進程使用的虛擬內存（VIRT）、進程使用的實際物理內存（RES）、共享內存（SHR）、CPU占用百分比、進程使用的物理內存百分比（%MEM）、進程使用的CPU時間總計（1/100秒，TIME+）、命令行
（1）top顯示的是進程信息，要看線程級，可用ps -ef
（2）TIME+表示的是進程使用的CPU時間總計，不是進程的存活時間
（3）默認不會顯示進程分布在那顆CPU上，如想分析CPU對應的應用程序，可修改top默認配置，添加字段Last used CPU即可。
（4）H：top配置幫助頁
d：刷新間隔
f：添加進程字段顯示列
1：顯示平均/各顆CPU的利用率信息
W：保存配置信息
6、top參數
-d 批處理模式
-c 命令/程序名 觸發
-d 設置延遲間隔（刷新頻率）
-n 設置迭代數量（退出前監控次數）
-p 監控特定的PID
-u或-U: 用戶名 或 UID
top -b -d 1 -n 3 > top.log
tomcat監控之probe
目前流行的中間件有tomcat、jetty、Jboss、weblogic、WebSphere等，基本原理相似，都遵循servlet規范。對容器的監控實際上是對JVM的監控，容器運行在JVM紙上。JVM的監控分析工具有jvisualVM、jconsole、jprofiler、zabbix、nagios、cacti等。下面介紹tomcat監控工具probe，probe只需要一個war包就可以完成監控任務，完全不用設置，下面是tomcat常規監控項：
| 類別 | 計數器 | 描述 |
| tomcat | JVM內存 | 關注GC回收頻率，Full GC次數越少越好 |
| 最大線程數 | 線程池連接數長期大於80%以上，建議優化 | |
| 數據庫連接數 | 活動連接數長期大於80%以上，建議優化連接池 | |
| 請求數 請求狀態 |
線程數，線程狀態，大量blocked狀態線程可以dump線程棧信息進行優化 |
probe
安裝probe之后，打開瀏覽器訪問probe：127.0.0.1:8089/probe
線程池的監控：
current_threads_count：線程池中ready好的數量，我的在運行狀態，我的在等待狀態
current_threads_busy：當前活動狀態的線程數量，正處在活動狀態
max_threads：最大線程池數量
我們需要關注current_threads_count和current_threads_busy是否接近max_threads,如果是，則需要加大max_threads數量；如果服務器硬件支撐不了更多線程數，就需要更換更強的硬件或做集群來分擔負載。
JVM監控
除了probe之外，自帶監控工具也比較好用
jps
jps是jdk提供的一個查看當前java進程的小工具， 可以看做是JavaVirtual Machine Process Status Tool的縮寫。非常簡單實用。
jps –l:輸出主類或者jar的完全路徑名
jps –v :輸出jvm參數
jps –q ：僅僅顯示java進程號
jps -m : 輸出main method的參數
jps -mlv 10.134.68.173 （如果需要查看其他機器上的jvm進程，需要在待查看機器上啟動jstatd。）
jstat
FGC(Full gc)會暫停用戶相應，也就是不處理用戶請求，等待Full gc完成后響應用戶請求，這個等待時間過大會影響用戶體驗，所以Full gc是JVM調優的重點
jstat -gcutil [PID]
jmap
分析程序內存占用其實是分析堆（Heap）內存，堆快照使用jamp獲取
典型獲取方式：
jmao dump:format=b,file=d:\heap.hprof [pid]
heap.hprof是快照文件，可以使用JVisualvm來打開
JVisualvm
JDK自帶的JVM可視化監控工具
在%JAVA_HOME%\bin下找到
,雙擊啟動
下圖：可以做堆Dump操作，查看堆內存明細。堆的回收曲線能夠直觀反映堆內存回收頻率，是否有內存溢出等問題。
下圖：點擊“線程Dump”導出JVM當前線程棧信息，通過分析這些信息來定位到程序問題
總結：對於Java的應用來講，JVM的性能反映了Java程序的性能，JVM的監控分兩大類，一是堆內存，二是線程；從堆內存可以分析大對象與內存溢出等問題，從線程狀態及線程信息分析出低效程序，解決的是CPU資源占用的問題。
MySql監控之MONyog
MySql監控方法：官方客戶端、命令行、SQL、MONyog
1、下載MONyog.地址：https://www.webyog.com/
2、安裝完成后，啟動MONyog進行連接配置
3、MONyog絕大多數指標都進行了詳細說明
最后
當性能測試環境復雜的情況下，可以借助zabbix、nagios、cacti等監控平台