2021-03-15 分類: 網(wǎng)站建設(shè)
在實(shí)際的生產(chǎn)運(yùn)行、測試過程中,一般都會(huì)關(guān)注吞吐量、響應(yīng)時(shí)間、CPU利用率,在開發(fā)和測試階段,我們不但需要關(guān)注,而且要通過它們之間的關(guān)系來驗(yàn)證測試的結(jié)果是否可信、分析性能問題在哪里。
吞吐量和響應(yīng)時(shí)間的關(guān)系
這里先舉一個(gè)例子,通過計(jì)算,發(fā)現(xiàn)測試結(jié)果不可信的例子。
該場景是服務(wù)器并發(fā)處理業(yè)務(wù)報(bào)文,并且達(dá)到了大處理能力(即TPS達(dá)到大,如果再增加壓力,就出現(xiàn)擁堵現(xiàn)象),性能測試結(jié)果如下:
看了之后結(jié)果,我立刻說:不可能
原因如下:這個(gè)場景中TPS=14,一共有20個(gè)進(jìn)程并發(fā)處理。那么每個(gè)進(jìn)程每秒鐘處理的業(yè)務(wù)個(gè)數(shù)=14/20=0.7個(gè)。
那么每個(gè)業(yè)務(wù)的響應(yīng)時(shí)間(理論計(jì)算)=1(秒)/0.7=1.43秒。
而測試結(jié)果顯示,業(yè)務(wù)響應(yīng)時(shí)間為240毫秒(0.24秒),這中間的1.42-0.24秒哪里去了?這個(gè)結(jié)果一定不可信。隨即,我咨詢對(duì)于響應(yīng)時(shí)間的統(tǒng)計(jì)方式。得到的答復(fù)是:統(tǒng)計(jì)工具從日志里面統(tǒng)計(jì)的。好吧,只能打開原始日志看了。
原始日志中每個(gè)業(yè)務(wù)有5個(gè)時(shí)間戳,我姑且叫它們ABCDE吧。
A:客戶端發(fā)起的時(shí)間(按照客戶端的機(jī)器時(shí)間給打的時(shí)間戳)
B:服務(wù)器端進(jìn)程從消息中間件中取出消息的時(shí)間
C:服務(wù)器端開始處理的時(shí)間
D:進(jìn)程認(rèn)為自己處理結(jié)束的時(shí)間
E:寫這一條日志的時(shí)間
當(dāng)前的統(tǒng)計(jì)方式是D-C。
問:為什么不是E-B?
答:開發(fā)人員說按照D-C
好吧,不扯那么多了,計(jì)算吧。
計(jì)算幾萬條業(yè)務(wù)的E-B的平均時(shí)間,1573.34毫秒,和我們理論的計(jì)算(1.43秒)基本吻合。
所以,之前的統(tǒng)計(jì)方法是錯(cuò)誤的。
和CPU利用率的關(guān)系
舉第二個(gè)例子,和CPU利用率相關(guān)的例子。
這個(gè)例子中,同樣是服務(wù)器并發(fā)處理某類業(yè)務(wù)報(bào)文,性能測試結(jié)果如下:
平均響應(yīng)時(shí)間是198.78毫秒,即0.19878秒。那么每個(gè)進(jìn)程每秒鐘處理的業(yè)務(wù)個(gè)數(shù)=1/0.19878=5個(gè)。
服務(wù)器一共設(shè)置了大20個(gè)進(jìn)程并發(fā)處理。那么如果這20個(gè)進(jìn)程都被調(diào)用起來全速處理的話,它們的大處理能力是每秒鐘=20*5=100個(gè)。
而當(dāng)前的TPS=52.46,相當(dāng)于大能力(100)的52.46%,那么CPU利用率也應(yīng)該差不多這個(gè)數(shù),我們實(shí)測的CPU利用率是56%,考慮隨著TPS的增加,業(yè)務(wù)響應(yīng)時(shí)間也是會(huì)變化的,系統(tǒng)的CPU也不是完全線性變化的,上述的計(jì)算推測已經(jīng)是非常吻合實(shí)際情況了。說明這個(gè)測試當(dāng)中,各個(gè)系統(tǒng)性能數(shù)據(jù)之間是可以從數(shù)字關(guān)系上對(duì)上號(hào),說明他們的取值都是正確的。
這里還要多說一點(diǎn),在虛擬化環(huán)境下,大多數(shù)人對(duì)AIX/Power系統(tǒng)的CPU利用率取值是錯(cuò)誤的,因此拿起測試結(jié)果大致一算,是對(duì)CPU利用率取值的快速驗(yàn)證。虛擬化環(huán)境下Power系統(tǒng)的CPU利用率取值我在之前的文章中有過介紹,感興趣的同學(xué)可以回看。
楊建旭,師從中國工程院院士陳純教授,于2006年獲得浙江大學(xué)計(jì)算機(jī)學(xué)院碩士學(xué)位,曾獲得授權(quán)發(fā)明專利10余項(xiàng)、SCI/EI索引論文8篇?,F(xiàn)任中國人民銀行清算總中心性能測試團(tuán)隊(duì)負(fù)責(zé)人,高級(jí)技術(shù)經(jīng)理。曾就職于VIA(中國)、VMware(中國),對(duì)虛擬化趨勢下銀行業(yè)系統(tǒng)的性能測試、問題分析、性能調(diào)優(yōu)有豐富的經(jīng)驗(yàn)。
擴(kuò)展閱讀:
CPU利用率異常的分析思路和方法QA——虛擬化相關(guān)
(一) PowerVM環(huán)境下的CPU監(jiān)控和分析與物理機(jī)環(huán)境有哪些差異?
首先:利用率的概念不同。
虛擬化環(huán)境下CPU利用率相對(duì)于EC(標(biāo)稱計(jì)算能力)來說,可以超過100%。
相對(duì)于VP(虛擬CPU)來說,永遠(yuǎn)是<=100%。
相對(duì)于運(yùn)行時(shí)獲得的物理CPU來說,永遠(yuǎn)是<=100%。
CPU利用率的統(tǒng)計(jì)方法:
若physical CPU沒有超過EC,則采集EC利用率。
當(dāng)Physical CPU<=EC時(shí),EC利用率=(EC_User% + EC_Sys%)/EC值。
Nmon CPU_ALL Sheet:CPU%
或Nmon LPAR Sheet:EC_User% + EC_Sys%
若physical CPU超過EC:
此時(shí)若按照EC利用率統(tǒng)計(jì),則CPU利用率很可能超過了100%,出具的測試結(jié)果、測試報(bào)告容易造成誤解。
此時(shí)若按照physical CPU利用率(使用的CPU/physical CPU)統(tǒng)計(jì),分母physical CPU是動(dòng)態(tài)的,因此利用率不具有參考價(jià)值。
如果一定要統(tǒng)計(jì)CPU利用率,可按照VP利用率統(tǒng)計(jì),VP利用率= VP_User% + VP_Sys%。但需要假設(shè)CPU物理Core的個(gè)數(shù)為VP個(gè)數(shù)。舉例說明:
假設(shè)EC=2,VP=8,EC利用率為200%,VP利用率為50%。在測試報(bào)告中描述CPU利用率為50%(CPU為8核,其中EC為2C,借用為借用資源池)。
第二:虛擬化環(huán)境關(guān)注的參數(shù)更多,這些參數(shù)會(huì)對(duì)性能產(chǎn)生巨大的影響。
虛擬化環(huán)境需同時(shí)關(guān)注以下參數(shù):
CPU核數(shù)
標(biāo)稱計(jì)算能力(Entitled Capacity,簡稱EC)
虛擬CPU(Virtual CPU,簡稱VP)
邏輯CPU個(gè)數(shù)(Logical CPU)
SMT
有上限/無上限(Capped/Uncapped)
型號(hào)/時(shí)鐘頻率
處理器折疊(Processor Folding)
運(yùn)行時(shí)物理CPU(Physical CPU)
(二) 開發(fā)的應(yīng)用在CPU核數(shù)一樣的虛擬服務(wù)器上性能表現(xiàn)出較大的差異
1、用的是什么虛擬服務(wù)器?VMware還是PowerVM的?還是其他的平臺(tái)?
2、假如是VMware,用的是ESX/vSphere還是VMware Workstation,二者架構(gòu)不同,性能不同,PC上的VMware Workstation不是裸金屬模式,性能不好。
3、虛擬機(jī)上看到的核數(shù),可能不是真正的核數(shù)。比如說VMware上,看到的2個(gè)core,其實(shí)是x86 CPU的一個(gè)core中的一個(gè)超線程。
如果這個(gè)x86 CPU一個(gè)core是兩個(gè)線程,那么虛擬機(jī)中的兩個(gè)core只相當(dāng)于物理的一個(gè)core。當(dāng)然,這是能夠完全搶占的情況下。如果沒有完全搶占,那就更小了。
如果是PowerVM的虛擬機(jī),操作系統(tǒng)看到的核數(shù)是VP(虛擬CPU),至于這個(gè)LPAR運(yùn)行時(shí)候,能得到多少物理CPU以及這些物理CPU的親和性,可能差異很大。
(三) 虛擬化下CPU核數(shù)超分配有沒有好實(shí)踐
問題:在虛擬化的環(huán)境下,一般可以超分配CPU核數(shù)。一般會(huì)有一個(gè)臨界值。過了這個(gè)值CPU性能就大幅下滑。我們?nèi)绾握疫@個(gè)值,有沒有什么好實(shí)踐?
所謂的“好實(shí)踐”其實(shí)是廠商給出通用值,具體到你的單位頭上,并不一定是好的。世界上沒有所謂的通用的好。就好比,兩地三中心、異地雙活之類的設(shè)計(jì)方案,沒有什么好實(shí)踐,每個(gè)企業(yè)都有根據(jù)自己的特點(diǎn)來設(shè)計(jì)。
回到你的問題,如果你的系統(tǒng)追求最短的響應(yīng)時(shí)間(核心交易系統(tǒng)),VP和EC的比值越小越好。如果,追求大瞬時(shí)CPU獲得,設(shè)置大一些更好,大可以是10,適用于平時(shí)沒有什么業(yè)務(wù)量的非核心系統(tǒng)。
(四) EC高低似乎對(duì)業(yè)務(wù)響應(yīng)時(shí)間沒什么影響,為什么?
問題1:
解答1:
這個(gè)是需要運(yùn)氣的。
是否做上下文切換,取決于進(jìn)程是不是每次被調(diào)用到同一個(gè)VP上,VP是不是每次被調(diào)用到同一個(gè)物理CPU上。
如果你的資源池,資源比較充足,那么hypervisor按照親和性調(diào)度,你的VP每次得到的物理CPU是一樣的,所以響應(yīng)時(shí)間不受影響
反之,資源緊張,多個(gè)LPAR爭搶,親和性大打折扣,響應(yīng)時(shí)間就起伏很大。
親和性的數(shù)值,可以通過下面方式查詢
Nmon的BBBP sheet
命令行Mpstat –d
問題2:
"那么如果要看運(yùn)氣的話,物理資源多少才算閑置,總利用率多少需要開始關(guān)注CPU親和度了,需要開始著手處理此類問題了"
解答2:
首先要理解親和度的概念,是CPU是否能從cache1、2、3里面讀到數(shù)據(jù)。舉個(gè)例子,有1000個(gè)進(jìn)程跑在一個(gè)CPU上,但都是不怎么干活的進(jìn)程,一會(huì)兒進(jìn)程A上來占用,一會(huì)進(jìn)程B上來占用,但總體CPU利用率并不高,但每個(gè)進(jìn)程上來后都要有自己的進(jìn)程上下文??赡艽藭r(shí)cache1、2、3根本緩存不了這么多上下文。結(jié)果就是大量的上下文切換。
因此不會(huì)有一個(gè)絕對(duì)的指標(biāo),說物理資源多少才開始關(guān)注CPU親和度。
針對(duì) “物理機(jī)的整體CPU利用率究竟達(dá)到多少時(shí),需要考慮擴(kuò)大LPAR的EC”
是否擴(kuò)大LPAR的EC,主要考慮的是你的業(yè)務(wù)需求是否能夠得到滿足(例如,響應(yīng)時(shí)間是否滿足要求,吞吐量是否跟得上),而不是主要考慮物理機(jī)的整體CPU利用率。
當(dāng)前標(biāo)題:吞吐量、響應(yīng)時(shí)間和CPU利用率之間的關(guān)系
分享地址:http://jinyejixie.com/news/105220.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供用戶體驗(yàn)、外貿(mào)建站、ChatGPT、網(wǎng)站維護(hù)、定制開發(fā)、搜索引擎優(yōu)化
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容