性能監控實戰

時間 2019-11-29

標籤性能監控實戰欄目系統性能简体版

原文原文鏈接

用戶響應時間=服務器響應時間+網絡時間java

系統性能分析思路

（1）總體系統CPU利用率mysql

（2）內存利用率linux

（3）磁盤I/O的利用率和延遲ios

（4）網絡利用率web

cpu

CPU：top、vmstat、uptime、sarsql

　　通常咱們指望會指望系統平都可用的CPU很多於20%數據庫

JVM自帶監控命令：jstat、jmap、Jvisualvm、JConsole瀏覽器

Mysql監控工具：Spolight、Monyog、及命令行工具緩存

內存

　　　　 total　　　　　　used　　　　　　　　free　　　　　　　　　buffers　　　　　　　　　cached　tomcat

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

類型	度量方法	衡量標準
使用狀況	一、vmstat 統計1-%id的計數二、sar -u 統計1-%idle的計數三、dstat 統計1-%idl的計數四、mpstat -P ALL 統計%idle的計數五、ps 統計CPU的計數	注意>=50% 告警>=70% 嚴重>=90%
滿載	六、vmstat的r計數器> cpu邏輯顆數七、sar -q ,「runq-sz」>cpu邏輯顆數八、dstat -q ,「run」>cpu邏輯顆數	運行隊列大於1時，證實已經有必定的負載了，不過這個計數也不絕對，須要進一步分期其餘的資源狀況來判定是否CPU已經滿負荷運做
錯誤	九、perf工具捕獲處理器的錯誤信息，需處理器支持	安裝perf：yum install perf* 需處理器支持

內存定位分析

監控命令：vmstat、sar、dstat、free、top、ps等

類型	度量方法	衡量標註
使用狀況	一、free 查看使用狀況二、vmstat 三、sar -r 四、ps	注意>=50% 告警>=70% 嚴重>=80%
滿載	五、vmstat的si/so比例輔助swapd和free利用六、sar -W 查看次缺頁數七、查看內核日誌有誤OOM機制kill進程八、dmesg \| grep killed	一、so數值大，且swapd已經佔比很高，內存確定已經飽和二、sar命令次缺頁多意味已經在不定地和swap打交道，證實內存已經飽和三、但內存不夠用會出發內核的OOM機制
錯誤	九、查看內核有無physical failures 十、經過工具如valgrind等進行檢查	有計數

網絡定位分析

監控命令：sar、ifconfig、netstat，以及查看net的dev速率，經過查看發現收發包的吞吐率達到網卡的最大上限，網絡數據報文有由於這類緣由而引發的丟包、阻塞等現象都證實當前網絡可能存在瓶頸。在進行性能測試是爲了減少網絡的影響，通常咱們都在局域網中進行測試執行。

類型	度量方法	衡量標準
使用狀況	一、sar -n DEV 的收發計數大於網卡上限二、ifconfig RX/TX寬帶超過網卡上限三、cat /proc/net/dev的速率超過上限四、nicstat的util基本滿負荷	一、收發包的吞吐速率達到網卡上限二、有延遲三、有丟包四、有阻塞
滿載	五、ifconfig dropped 有計數六、netstat -s "segments retransmited"有計數七、sar -n EDEV，rxdrop/s txdrop/s有計數	統計的丟包有計數證實已經滿了
錯誤	八、ifconfig，「errors」九、netstat -i，RX-ERR TX-ERR 10 sar -n EDEV，rxerr/s txerr/s 十一、ip -s link，「errors」	錯誤有計數

IO定位分析

監控命令：sar、iostat、iotop

類型	度量方法	衡量標準
使用狀況	一、iostat -xz，「%util」二、sar -d，「%util」三、iotop的利用率很高四、cat /proc/pid/sched \| grep iowait	注意>=40% 告警>=60% 嚴重>=80%
滿載	五、iostat -xnz，「avgqu-sz 」>1 六、iostat await>70	IO已經有滿載嫌疑
錯誤	七、dmseg 查看io錯誤八、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

一、第一行：uptime同樣

二、第二行：運行狀態信息

　　運行、睡眠、中斷、僵死

三、第三行：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

四、第四行+第五行：內存使用狀況

　　buffer和cache的做用是縮短IO系統調用的時間。若是頻繁地訪問文件都能被命中，很明顯會比讀取磁盤調用快，磁盤的IO一定會減少。cache的命中率很關鍵，若是不能命中，對cache而言是極大的浪費，此時應考慮drop cache並提高相應的cache命中率。

五、第六行：進程信息

　　進程號（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：保存配置信息

六、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線程棧信息進行優化