吞吐量、響應時間和 CPU 利用率之間的關係
在實際的生產執行、測試過程中,一般都會關注吞吐量、響應時間、CPU利用率,在開發和測試階段,我們不但需要關注,而且要通過它們之間的關係來驗證測試的結果是否可信、分析效能問題在哪裡。
吞吐量和響應時間的關係
這裡先舉一個例子,通過計算,發現測試結果不可信的例子。
該場景是伺服器併發處理業務報文,並且達到了最大處理能力(即TPS達到最大,如果再增加壓力,就出現擁堵現象),效能測試結果如下:
看了之後結果,我立刻說:不可能
原因如下:這個場景中TPS=14,一共有20個程序併發處理。那麼每個程序每秒鐘處理的業務個數=14/20=0.7個。
那麼每個業務的響應時間(理論計算)=1(秒)/0.7=1.43秒。
而測試結果顯示,業務響應時間為240毫秒(0.24秒),這中間的1.42-0.24秒哪裡去了?這個結果一定不可信。隨即,我諮詢對於響應時間的統計方式。得到的答覆是:統計工具從日誌裡面統計的。好吧,只能開啟原始日誌看了。
原始日誌中每個業務有5個時間戳,我姑且叫它們ABCDE吧。
A:客戶端發起的時間(按照客戶端的機器時間給打的時間戳)
B:伺服器端程序從訊息中介軟體中取出訊息的時間
C:伺服器端開始處理的時間
D:程序認為自己處理結束的時間
E:寫這一條日誌的時間
當前的統計方式是D-C。
問:為什麼不是E-B?
答:開發人員說按照D-C
好吧,不扯那麼多了,計算吧。
計算幾萬條業務的E-B的平均時間,1573.34毫秒,和我們理論的計算(1.43秒)基本吻合。
所以,之前的統計方法是錯誤的。
和CPU利用率的關係
舉第二個例子,和CPU利用率相關的例子。
這個例子中,同樣是伺服器併發處理某類業務報文,效能測試結果如下:
平均響應時間是198.78毫秒,即0.19878秒。那麼每個程序每秒鐘處理的業務個數=1/0.19878=5個。
伺服器一共設定了最大20個程序併發處理。那麼如果這20個程序都被呼叫起來全速處理的話,它們的最大處理能力是每秒鐘=20*5=100個。
而當前的TPS=52.46,相當於最大能力(100)的52.46%,那麼CPU利用率也應該差不多這個數,我們實測的CPU利用率是56%,考慮隨著TPS的增加,業務響應時間也是會變化的,系統的CPU也不是完全線性變化的,上述的計算推測已經是非常吻合實際情況了。說明這個測試當中,各個系統性能資料之間是可以從數字關係上對上號,說明他們的取值都是正確的。
這裡還要多說一點,在虛擬化環境下,大多數人對AIX/Power系統的CPU利用率取值是錯誤的,因此拿起測試結果大致一算,是對CPU利用率取值的快速驗證。虛擬化環境下Power系統的CPU利用率取值我在之前的文章中有過介紹,感興趣的同學可以回看。
楊建旭,師從中國工程院院士陳純教授,於2006年獲得浙江大學計算機學院碩士學位,曾獲得授權發明專利10餘項、SCI/EI索引論文8篇。現任中國人民銀行清算總中心效能測試團隊負責人,高階技術經理。曾就職於VIA(中國)、VMware(中國),對虛擬化趨勢下銀行業系統的效能測試、問題分析、效能調優有豐富的經驗。
擴充套件閱讀:
C PU利用率異常的分析思路和方法QA——虛擬化相關
(一) PowerVM環境下的CPU監控和分析與物理機環境有哪些差異?
首先:利用率的概念不同。
虛擬化環境下CPU利用率相對於EC(標稱計算能力)來說,可以超過100%。
相對於VP(虛擬CPU)來說,永遠是<=100%。
相對於執行時獲得的物理CPU來說,永遠是<=100%。
CPU利用率的統計方法:
若physical CPU沒有超過EC,則採集EC利用率。
當Physical CPU<=EC時,EC利用率=(EC_User% + EC_Sys%)/EC值。
Nmon CPU_ALL Sheet:CPU%
或Nmon LPAR Sheet:EC_User% + EC_Sys%
若physical CPU超過EC:
此時若按照EC利用率統計,則CPU利用率很可能超過了100%,出具的測試結果、測試報告容易造成誤解。
此時若按照physical CPU利用率(使用的CPU/physical CPU)統計,分母physical CPU是動態的,因此利用率不具有參考價值。
如果一定要統計CPU利用率,可按照VP利用率統計,VP利用率= VP_User% + VP_Sys%。但需要假設CPU物理Core的個數為VP個數。舉例說明:
假設EC=2,VP=8,EC利用率為200%,VP利用率為50%。在測試報告中描述CPU利用率為50%(CPU為8核,其中EC為2C,借用為借用資源池)。
第二:虛擬化環境關注的引數更多,這些引數會對效能產生巨大的影響。
虛擬化環境需同時關注以下引數:
CPU核數
標稱計算能力(Entitled Capacity,簡稱EC)
虛擬CPU(Virtual CPU,簡稱VP)
邏輯CPU個數(Logical CPU)
SMT
有上限/無上限(Capped/Uncapped)
型號/時鐘頻率
處理器摺疊(Processor Folding)
執行時物理CPU(Physical CPU)
(二) 開發的應用在CPU核數一樣的虛擬伺服器上效能表現出較大的差異
1、用的是什麼虛擬伺服器?VMware還是PowerVM的?還是其他的平臺?
2、假如是VMware,用的是ESX/vSphere還是VMware Workstation,二者架構不同,效能不同,PC上的VMware Workstation不是裸金屬模式,效能不好。
3、虛擬機器上看到的核數,可能不是真正的核數。比如說VMware上,看到的2個core,其實是x86 CPU的一個core中的一個超執行緒。
如果這個x86 CPU一個core是兩個執行緒,那麼虛擬機器中的兩個core只相當於物理的一個core。當然,這是能夠完全搶佔的情況下。如果沒有完全搶佔,那就更小了。
如果是PowerVM的虛擬機器,作業系統看到的核數是VP(虛擬CPU),至於這個LPAR執行時候,能得到多少物理CPU以及這些物理CPU的親和性,可能差異很大。
(三) 虛擬化下CPU核數超分配有沒有最佳實踐
問題:在虛擬化的環境下,一般可以超分配CPU核數。一般會有一個臨界值。過了這個值CPU效能就大幅下滑。我們如何找這個值,有沒有什麼最佳實踐?
所謂的“最佳實踐”其實是廠商給出通用值,具體到你的單位頭上,並不一定是最佳的。世界上沒有所謂的通用的最佳。就好比,兩地三中心、異地雙活之類的設計方案,沒有什麼最佳實踐,每個企業都有根據自己的特點來設計。
回到你的問題,如果你的系統追求最短的響應時間(核心交易系統),VP和EC的比值越小越好。如果,追求最大瞬時CPU獲得,設定大一些更好,最大可以是10,適用於平時沒有什麼業務量的非核心繫統。
(四) EC高低似乎對業務響應時間沒什麼影響,為什麼?
問題1:
解答1:
這個是需要運氣的。
是否做上下文切換,取決於程序是不是每次被呼叫到同一個VP上,VP是不是每次被呼叫到同一個物理CPU上。
如果你的資源池,資源比較充足,那麼hypervisor按照親和性排程,你的VP每次得到的物理CPU是一樣的,所以響應時間不受影響
反之,資源緊張,多個LPAR爭搶,親和性大打折扣,響應時間就起伏很大。
親和性的數值,可以通過下面方式查詢
Nmon的BBBP sheet
命令列Mpstat –d
問題2:
"那麼如果要看運氣的話,物理資源多少才算閒置,總利用率多少需要開始關注CPU親和度了,需要開始著手處理此類問題了"
解答2:
首先要理解親和度的概念,是CPU是否能從cache1、2、3裡面讀到資料。舉個例子,有1000個程序跑在一個CPU上,但都是不怎麼幹活的程序,一會兒程序A上來佔用,一會程序B上來佔用,但總體CPU利用率並不高,但每個程序上來後都要有自己的程序上下文。可能此時cache1、2、3根本快取不了這麼多上下文。結果就是大量的上下文切換。
因此不會有一個絕對的指標,說物理資源多少才開始關注CPU親和度。
針對 “物理機的整體CPU利用率究竟達到多少時,需要考慮擴大LPAR的EC”
是否擴大LPAR的EC,主要考慮的是你的業務需求是否能夠得到滿足(例如,響應時間是否滿足要求,吞吐量是否跟得上),而不是主要考慮物理機的整體CPU利用率。