吞吐量、响应时间和CPU利用率之间的关系

2021-03-15    分类: 网站建设

在实际的生产运行、测试过程中,一般都会关注吞吐量、响应时间、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(中国),对虚拟化趋势下银行业系统的性能测试、问题分析、性能调优有丰富的经验。

扩展阅读:

CPU利用率异常的分析思路和方法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利用率。

当前标题:吞吐量、响应时间和CPU利用率之间的关系
分享地址:https://www.cdcxhl.com/news/105220.html

成都网站建设公司_创新互联,为您提供用户体验外贸建站ChatGPT网站维护定制开发搜索引擎优化

广告

声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联

搜索引擎优化