CPU load Avg && CPU CpuUsage

Cpu负载和cpu利用率的区别

CPU利用率:显示的是程序在运行期间实时占用的CPU百分比

CPU负载:显示的是一段时间内正在使用和等待使用CPU的平均任务数。CPU利用率高，并不意味着负载就一定大。举例来说：如果我有一个程序它需要一直使用cpu的运算功能，那么此时cpu的使用率可能达到100%，但是cpu的工作负载则是趋近于“1”，因为cpu仅负责一个工作嘛！如果同时执行这样的程序两个呢？cpu的使用率还是100%，但是工作负载则变成2了。所以也就是说，当cpu的工作负载越大，代表cpu必须要在不同的工作之间进行频繁的工作切换。

l 举例说明

网上有篇文章举了一个有趣比喻，拿打电话来说明两者的区别，我按自己的理解阐述一下。

某公用电话亭，有一个人在打电话，四个人在等待，每人限定使用电话一分钟，若有人一分钟之内没有打完电话，只能挂掉电话去排队，等待下一轮。电话在这里就相当于CPU，而正在或等待打电话的人就相当于任务数。

在电话亭使用过程中，肯定会有人打完电话走掉，有人没有打完电话而选择重新排队，更会有新增的人在这儿排队，这个人数的变化就相当于任务数的增减。为了统计平均负载情况，我们5分钟统计一次人数，并在第1、5、15分钟的时候对统计情况取平均值，从而形成第1、5、15分钟的平均负载。

有的人拿起电话就打，一直打完1分钟，而有的人可能前三十秒在找电话号码，或者在犹豫要不要打，后三十秒才真正在打电话。如果把电话看作CPU，人数看作任务，我们就说前一个人（任务）的CPU利用率高，后一个人（任务）的CPU利用率低。

当然， CPU并不会在前三十秒工作，后三十秒歇着，只是说，有的程序涉及到大量的计算，所以CPU利用率就高，而有的程序牵涉到计算的部分很少，CPU利用率自然就低。但无论CPU的利用率是高是低，跟后面有多少任务在排队没有必然关系。

 

什么是QPS：

QPS是每秒钟处理完请求的次数。这里的请求不是指一个查询或者数据库查询，是包括一个业务逻辑的整个流程，也就是说每秒钟响应的请求次数。

什么是响应时间：

响应时间即RT，处理一次请求所需要的平均处理时间。对于RT，客户端和服务端是大不相同的，因为请求从客户端到服务端，需要经过广域网，所以客户端RT往往远大于服务端RT，同时客户端的RT往往决定着用户的真实体验，服务端RT往往是评估我们系统好坏的一个关键因素。

最佳线程数的困扰：

在开发过程中，我们一定面临过很多的线程数量的配置问题，这种问题往往让人摸不到头脑，往往都是拍脑袋给出一个线程池的数量，但这可能恰恰是不靠谱的，过小的话会导致请求RT极具增加，过大也一样RT也会升高。所以对于最佳线程数的评估往往比较麻烦。

QPS和RT的关系：

单线程场景：

假设我们的服务端只有一个线程，那么所有的请求都是串行执行，我们可以很简单的算出系统的QPS，也就是：QPS = 1000ms/RT。假设一个RT过程中CPU计算的时间为49ms，CPU Wait Time 为200ms，那么QPS就为1000/49+200 = 4.01。

多线程场景

我们接下来把服务端的线程数提升到2，那么整个系统的QPS则为：2 *（1000/49+200）=8.02。可见QPS随着线程的增加而线性增长，那QPS上不去就加线程呗，听起来很有道理，公式也说得通，但是往往现实并非如此，后面会聊这个问题。

最佳线程数？

从上面单线程场景来看，CPU Wait time为200ms,你可以理解为CPU这段时间什么都没做，是空闲的，显然我们没把CPU利用起来，这时候我们需要启多个线程去响应请求，把这部分利用起来，那么启动多少个线程呢？我们可以估算一下 空闲时间200ms，我们要把这部分时间转换为CPU Time,那么就是200+49/49 = 5.08个，不考虑上下文切换的话，约等于5个线程。同时还要考虑CPU的核心数和利用率问题，那么我们得到了最佳线程数计算的公式：RT/CPU Time * coreSize * cupRatio

最大QPS？

得到了最大的线程数和QPS的计算方式：

QPS = Thread num * 单线程QPS = （CPU Time + CPU Wait Time）/CPU Time * coreSize * CupRatio * (1000ms/(CPU Time + CPU Wait Time)) = 1000ms/(CPU Time) * coreSize * cpuRatio

所以决定一个系统最大的QPS的因素是CPU Time、CoreSize和CPU利用率。看似增加CPU核数（或者说线程数）可以成倍的增加系统QPS，但实际上增加线程数的同时也增加了很大的系统负荷，更多的上下文切换，QPS和最大的QPS是有偏差的。

CPU Time & CPU Wait Time & CPU 利用率

CPU Time就是一次请求中，实际用到计算资源。CPU Time的消耗是全流程的，涉及到请求到应用服务器，再从应用服务器返回的全过程。实际上这取决于你的计算的复杂度。

CPU Wait Time是一次请求过程中对于IO的操作，CPU这段时间可以理解为空闲的，那么此时要尽量利用这些空闲时间，也就是增加线程数。

CPU 利用率是业务系统利用到CPU的比率，因为往往一个系统上会有一些其他的线程，这些线程会和CPU竞争计算资源，那么此时留给业务的计算资源比例就会下降，典型的像，GC线程的GC过程、锁的竞争过程都是消耗CPU的过程。甚至一些IO的瓶颈，也会导致CPU利用率下降(CPU都在Wait IO，利用率当然不高)。

增加CPU核数对QPS的提升

从上面的公式我们可以看出，假设CPU Time和CPU 利用率不变，增加CPU的核数能使QPS呈线性增长。但是很遗憾，现实中不是这样的....首先先看一下阿姆达尔定律：

阿姆达尔定律.png

阿姆达尔定律是一个很有意思的定律，简单的我们可以理解为，程序中可并行代码的比例决定你增加处理器（总核心数）所能带来的速度提升的上限
。换句话说就是串行化对于你系统吞吐量的影响。举个栗子:

1.坐车问题：

假设你想从望京去顺义，那么你智能坐着一辆车过去，虽然现在有十辆车，你也不能提升十倍的效率，这里F就是1，因为所有的动作都需要串行，speedup就等于1，效率没提升，虽然你有九辆车。

2.写代码问题：

假设你现在开发一个系统，你可以把所有的任务均分下去，假设10个人帮你开发，那么F就为0，N为10，那么speedup等于10，也就是说你提升了10倍的速率。

这里的N就是我们的核数。在F为0的时候可以成倍增加计算效率，但是很遗憾F不为0，同时随着你的请求数的增加，F的值也在增加，当这个串行率达到一定程度的时候，你的系统是没有任何效果的提升的。当F不变的时候，N增加，那么Speedup增加。但是当N->∞,那么整个公式就变成了1/F，也就是说当核数不断增大的时候，speedup是有上限的。
同样，对于1000ms/(CPU Time) * coreSize * cpuRatio我们不断的增加CoreSize或者说线程数的时候。我们的请求变多了，随之而来的就是大量的上下文切换、大量的GC、大量的锁征用，这些串行化的因素会大大增加F值，也会大大的增加CPU Time。假设我们的串行部分不变的话，增大核数，CPU不能得到充分的利用，利用率也会降低。所以，对于阿姆达尔定律而言，串行化的比率才是决定着是否能成倍增长效率的关键。也就是说最佳线程数也好，最大QPS也好，增加内核数量不一定能是系统指标有成倍的增长。更关键的是能改变自己的架构，减小串行的比率，让CPU更充分的利用，达到资源的最大利用率。

再看一下最佳线程数和最大QPS

通过上面一些例子，我们发现当线程数增加的时候，线程的上下文切换会增加，GC Time会增加。这也就导致CPU time 增加，QPS减小，RT也会随着增大。这显然不是我们希望的，我们希望的是在核数一定的情况下找到某个点，使系统的QPS最大，RT相对较小。所以我们需要不断的压测，调整线程池，找到这个QPS的峰值，并且使CPU的利用率达到100%,这样才是系统的最大QPS和最佳线程数。