服務器監控系統中最常用的性能指標有哪些

本篇內容介紹了“服務器監控系統中最常用的性能指標有哪些”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

PV 
PV是 Page View的縮寫。用戶通過瀏覽器訪問頁面，對應用服務器產生的每一次請求，
記為一個 PV。淘寶性能測試環境下，將這個概念做了延伸，系統真實處理的一個請求，視
為一個 PV。即，PV的概念也適用于接口。 
PV的統計一般可以通過監控埋點或者統計訪問日志統計得出。
說到PV還有個特殊的情況，叫PeakPV，指一天中 PV數達到的高峰PV值。
通過一些監控系統，也可以直觀看到統計數據。
QPS/TPS
QPS/TPS原本含義為：系統每秒能處理的請求/事務的數量，或者說吞吐量。在web應用我們更關注的是web應用每秒能處理的request數量。這個是衡量系統性能的重要指標。
QPS（TPS）= 并發數/平均響應時間。 
QPS的統計可以通過訪問日志統計對應時間的PV量除以對應時間求得。在性能測試中可以通過工具測試獲得。
一般經常統計的是高峰期PV對應的QPS。
ResponseTime響應時間
響應時間(RT)是指從客戶端發一個請求開始計時，到客戶端接收到從服務器端返回的響應結果結束所經歷的時間，響應時間由請求發送時間、網絡傳輸時間和服務器處理時間三部分組成。


LOAD負載
系統平均負載，被定義為在特定時間間隔內運行隊列中的平均進程數。如果一個進程滿
足以下條件則其就會位于運行隊列中：
-它沒有在等待 I/O操作的結果 
-它沒有主動進入等待狀態（也就是沒有調用'wait'） 
-沒有被停止（例如：等待終止）1
這個負載值比較理想的指標值是cpu個數*核數*0.7 ，如果超過長期超過過這個值就需要對系統進行警惕了。

CPU 資源
CPU 資源這里指應用服務系統的 CPU 資源占用率。CPU 資源是判斷系統處理能力以及應用運行是否穩定的重要參數。

JVM GC和FullGC
對于java應用的性能指標必定少不了GC的相關指標了。通常我們的應用應該盡量避免FGC。因為FGC會進行完全的垃圾清理，會使應用運行得很慢，所以需要通過設置合適的JVM參數和GC策略來避免FGC。通常監控的指標有GC次數和響應時間。

常用的性能指標還有內存占用，磁盤io等一些指標，這里就不一一列出。

上面介紹了一些性能指標的概念和統計方法，下面就講其中幾個之間的一些重要聯系和區別。

1. 容量預測
對于我們設計的系統，我們在上線前肯定需要測試下能接收用戶多大的訪問量。即希望評估出最大的日PV到來的時候，我們的系統是否能支撐。但怎么去評估呢，難道要造一個最大日pv的情景來測試？其實根據已有的經驗和數據，可以總結出了高峰QPS和日pv的關系。
 
我們通過每日的QPS和PV統計圖表可以發現，每日的曲線基本都是一致的。通過數學建模，我們可以發現高峰每臺服務器QPS=( (總 PV*80%)/(24*60*60*40%))/服務器數量1。其中80%和40%這2個數字是個不固定的參數，這個公式代表的意思是，在40%的時間（12小時）內產生80%總pv的QPS均值。對于不同的情景有不同的參數。
這樣我們就可以通過壓測應用獲取其高峰QPS，然后根據公式算出指定高峰QPS下的日PV，通過這樣來進行容量預測。
即：日預估PV=壓測QPS * （24*60*60*時間百分比）/0.8 * 機器數量

2. CPU 資源占用率 與 LOAD
按很多人的印象cpu占用率和load都是對當前cpu使用率的統計。但是實際上這2個指標還是有很大區別的。
cpu占用率很好理解，就是對cpu使用所占時間比率。而cpu load則是基于一段時間內等待cpu處理的任務隊列的平均長度。這個指標在高負載的情況下比cpu占用率具有更高的參考價值。因為在高負荷時段，cpu的占用率基本都接近100%，它無法反映機器負荷的程度。相反，通過統計任務隊列的長度可以反映出系統目前負荷是否嚴重，是否可控。
用下圖中公路與車輛的關系可以很好理解load的概念：
(系統是單處理器時)
 
當load等于1的時候，系統滿負荷，但是能滿足當前的系統需求；
當load小于1的時候，系統輕松運行；
當load大于1時候，有很多車輛等待進入公路，就如任務在等待cpu處理一樣，這時候cpu占用率根本無法分辨出load=1和load>1這2種情況。
所以讀懂load對于理解系統當前運行負荷是很有幫助的。

“服務器監控系統中最常用的性能指標有哪些”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！