在實際的生產(chǎn)運行、測試過程中，一般都會關(guān)注吞吐量、響應(yīng)時間、CPU利用率，在開發(fā)和測試階段，我們不但需要關(guān)注，而且要通過它們之間的關(guān)系來驗證測試的結(jié)果是否可信、分析性能問題在哪里。

吞吐量和響應(yīng)時間的關(guān)系

這里先舉一個例子，通過計算，發(fā)現(xiàn)測試結(jié)果不可信的例子。

該場景是服務(wù)器并發(fā)處理業(yè)務(wù)報文，并且達到了大處理能力(即TPS達到大，如果再增加壓力，就出現(xiàn)擁堵現(xiàn)象)，性能測試結(jié)果如下：

看了之后結(jié)果，我立刻說：不可能

原因如下：這個場景中TPS=14，一共有20個進程并發(fā)處理。那么每個進程每秒鐘處理的業(yè)務(wù)個數(shù)=14/20=0.7個。

那么每個業(yè)務(wù)的響應(yīng)時間(理論計算)=1(秒)/0.7=1.43秒。

而測試結(jié)果顯示，業(yè)務(wù)響應(yīng)時間為240毫秒(0.24秒)，這中間的1.42-0.24秒哪里去了?這個結(jié)果一定不可信。隨即，我咨詢對于響應(yīng)時間的統(tǒng)計方式。得到的答復(fù)是：統(tǒng)計工具從日志里面統(tǒng)計的。好吧，只能打開原始日志看了。

原始日志中每個業(yè)務(wù)有5個時間戳，我姑且叫它們ABCDE吧。

A：客戶端發(fā)起的時間(按照客戶端的機器時間給打的時間戳)

B：服務(wù)器端進程從消息中間件中取出消息的時間

C：服務(wù)器端開始處理的時間

D：進程認為自己處理結(jié)束的時間

E：寫這一條日志的時間

當前的統(tǒng)計方式是D-C。

問：為什么不是E-B?

答：開發(fā)人員說按照D-C

好吧，不扯那么多了，計算吧。

計算幾萬條業(yè)務(wù)的E-B的平均時間，1573.34毫秒，和我們理論的計算(1.43秒)基本吻合。

所以，之前的統(tǒng)計方法是錯誤的。

和CPU利用率的關(guān)系

舉第二個例子，和CPU利用率相關(guān)的例子。

這個例子中，同樣是服務(wù)器并發(fā)處理某類業(yè)務(wù)報文，性能測試結(jié)果如下：

平均響應(yīng)時間是198.78毫秒，即0.19878秒。那么每個進程每秒鐘處理的業(yè)務(wù)個數(shù)=1/0.19878=5個。

服務(wù)器一共設(shè)置了大20個進程并發(fā)處理。那么如果這20個進程都被調(diào)用起來全速處理的話，它們的大處理能力是每秒鐘=20*5=100個。

而當前的TPS=52.46，相當于大能力(100)的52.46%，那么CPU利用率也應(yīng)該差不多這個數(shù)，我們實測的CPU利用率是56%，考慮隨著TPS的增加，業(yè)務(wù)響應(yīng)時間也是會變化的，系統(tǒng)的CPU也不是完全線性變化的，上述的計算推測已經(jīng)是非常吻合實際情況了。說明這個測試當中，各個系統(tǒng)性能數(shù)據(jù)之間是可以從數(shù)字關(guān)系上對上號，說明他們的取值都是正確的。

這里還要多說一點，在虛擬化環(huán)境下，大多數(shù)人對AIX/Power系統(tǒng)的CPU利用率取值是錯誤的，因此拿起測試結(jié)果大致一算，是對CPU利用率取值的快速驗證。虛擬化環(huán)境下Power系統(tǒng)的CPU利用率取值我在之前的文章中有過介紹，感興趣的同學(xué)可以回看。

楊建旭，師從中國工程院院士陳純教授，于2006年獲得浙江大學(xué)計算機學(xué)院碩士學(xué)位，曾獲得授權(quán)發(fā)明專利10余項、SCI/EI索引論文8篇。現(xiàn)任中國人民銀行清算總中心性能測試團隊負責(zé)人，高級技術(shù)經(jīng)理。曾就職于VIA(中國)、VMware(中國)，對虛擬化趨勢下銀行業(yè)系統(tǒng)的性能測試、問題分析、性能調(diào)優(yōu)有豐富的經(jīng)驗。

擴展閱讀：

CPU利用率異常的分析思路和方法QA——虛擬化相關(guān)

(一) PowerVM環(huán)境下的CPU監(jiān)控和分析與物理機環(huán)境有哪些差異?

首先：利用率的概念不同。

虛擬化環(huán)境下CPU利用率相對于EC(標稱計算能力)來說，可以超過100%。

相對于VP(虛擬CPU)來說，永遠是<=100%。

相對于運行時獲得的物理CPU來說，永遠是<=100%。

CPU利用率的統(tǒng)計方法：

若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利用率統(tǒng)計，則CPU利用率很可能超過了100%，出具的測試結(jié)果、測試報告容易造成誤解。

此時若按照physical CPU利用率(使用的CPU/physical CPU)統(tǒng)計，分母physical CPU是動態(tài)的，因此利用率不具有參考價值。

如果一定要統(tǒng)計CPU利用率，可按照VP利用率統(tǒng)計，VP利用率= VP_User% + VP_Sys%。但需要假設(shè)CPU物理Core的個數(shù)為VP個數(shù)。舉例說明：

假設(shè)EC=2，VP=8，EC利用率為200%，VP利用率為50%。在測試報告中描述CPU利用率為50%(CPU為8核，其中EC為2C，借用為借用資源池)。

第二：虛擬化環(huán)境關(guān)注的參數(shù)更多，這些參數(shù)會對性能產(chǎn)生巨大的影響。

虛擬化環(huán)境需同時關(guān)注以下參數(shù)：

CPU核數(shù)

標稱計算能力(Entitled Capacity，簡稱EC)

虛擬CPU(Virtual CPU，簡稱VP)

邏輯CPU個數(shù)(Logical CPU)

SMT

有上限/無上限(Capped/Uncapped)

型號/時鐘頻率

處理器折疊(Processor Folding)

運行時物理CPU(Physical CPU)

(二) 開發(fā)的應(yīng)用在CPU核數(shù)一樣的虛擬服務(wù)器上性能表現(xiàn)出較大的差異

1、用的是什么虛擬服務(wù)器?VMware還是PowerVM的?還是其他的平臺?

2、假如是VMware，用的是ESX/vSphere還是VMware Workstation，二者架構(gòu)不同，性能不同，PC上的VMware Workstation不是裸金屬模式，性能不好。

3、虛擬機上看到的核數(shù)，可能不是真正的核數(shù)。比如說VMware上，看到的2個core，其實是x86 CPU的一個core中的一個超線程。

如果這個x86 CPU一個core是兩個線程，那么虛擬機中的兩個core只相當于物理的一個core。當然，這是能夠完全搶占的情況下。如果沒有完全搶占，那就更小了。

如果是PowerVM的虛擬機，操作系統(tǒng)看到的核數(shù)是VP(虛擬CPU)，至于這個LPAR運行時候，能得到多少物理CPU以及這些物理CPU的親和性，可能差異很大。

(三) 虛擬化下CPU核數(shù)超分配有沒有好實踐

問題：在虛擬化的環(huán)境下，一般可以超分配CPU核數(shù)。一般會有一個臨界值。過了這個值CPU性能就大幅下滑。我們?nèi)绾握疫@個值，有沒有什么好實踐?

所謂的“好實踐”其實是廠商給出通用值，具體到你的單位頭上，并不一定是好的。世界上沒有所謂的通用的好。就好比，兩地三中心、異地雙活之類的設(shè)計方案，沒有什么好實踐，每個企業(yè)都有根據(jù)自己的特點來設(shè)計。

回到你的問題，如果你的系統(tǒng)追求最短的響應(yīng)時間(核心交易系統(tǒng))，VP和EC的比值越小越好。如果，追求大瞬時CPU獲得，設(shè)置大一些更好，大可以是10，適用于平時沒有什么業(yè)務(wù)量的非核心系統(tǒng)。

(四) EC高低似乎對業(yè)務(wù)響應(yīng)時間沒什么影響，為什么?

問題1：

解答1：

這個是需要運氣的。

是否做上下文切換，取決于進程是不是每次被調(diào)用到同一個VP上，VP是不是每次被調(diào)用到同一個物理CPU上。

如果你的資源池，資源比較充足，那么hypervisor按照親和性調(diào)度，你的VP每次得到的物理CPU是一樣的，所以響應(yīng)時間不受影響

反之，資源緊張，多個LPAR爭搶，親和性大打折扣，響應(yīng)時間就起伏很大。

親和性的數(shù)值，可以通過下面方式查詢

Nmon的BBBP sheet

命令行Mpstat –d

問題2：

"那么如果要看運氣的話，物理資源多少才算閑置，總利用率多少需要開始關(guān)注CPU親和度了，需要開始著手處理此類問題了"

解答2：

首先要理解親和度的概念，是CPU是否能從cache1、2、3里面讀到數(shù)據(jù)。舉個例子，有1000個進程跑在一個CPU上，但都是不怎么干活的進程，一會兒進程A上來占用，一會進程B上來占用，但總體CPU利用率并不高，但每個進程上來后都要有自己的進程上下文。可能此時cache1、2、3根本緩存不了這么多上下文。結(jié)果就是大量的上下文切換。

因此不會有一個絕對的指標，說物理資源多少才開始關(guān)注CPU親和度。

針對 “物理機的整體CPU利用率究竟達到多少時，需要考慮擴大LPAR的EC”

是否擴大LPAR的EC，主要考慮的是你的業(yè)務(wù)需求是否能夠得到滿足(例如，響應(yīng)時間是否滿足要求，吞吐量是否跟得上)，而不是主要考慮物理機的整體CPU利用率。

新聞標題：吞吐量、響應(yīng)時間和CPU利用率之間的關(guān)系
瀏覽路徑：http://m.rwnh.cn/news20/105220.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供商城網(wǎng)站、自適應(yīng)網(wǎng)站、網(wǎng)站制作、網(wǎng)站設(shè)計公司、網(wǎng)站建設(shè)、小程序開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)