吞吐量、响应时间和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(中国)，对虚拟化趋势下银行业系统的性能测试、问题分析、性能调优有丰富的经验。

扩展阅读：

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利用率之间的关系
浏览路径：/news20/105220.html

成都网站建设公司_创新互联，为您提供星空体育app最新版本(2024已更新)、自适应网站、网站制作、网站设计公司、网站建设、小程序开发

广告

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