卸载（Offloading）vs. 加载（Onloading）：谁是CPU利用率之王？

如今网络领域的主要争议话题之一是，是将网络功能加载到 CPU 上更合适，还是将这些功能卸载到互连硬件上更为理想。

Mellanox公司市场部副总裁Gilad Shainer

加载（Onloading）互连技术更易于实现，但问题在于对 CPU 利用率的影响由于CPU必须管理和执行网络操作，因此采用加载互连技术会降低其对应用程序的可用性——而这却是 CPU 的主要用途。

另一方面，卸载（Offloading）技术寻求克服 CPU 的性能瓶颈，主要方式是对在群集内移动的数据执行各种网络功能以及复杂的通信操作，如协同操作和数据聚集操作。当今数据分布范围广，在等待数据到达 CPU 处进行分析时就会产生性能瓶颈。相反，使用从 CPU 卸载这些功能的智能网络设备，就可在网络中的数据所在的位置进行操作。这一技术还有附加的优势：增加 CPU 对于计算功能的可用性，从而提升系统的整体效率。

CPU 利用率的问题是这两种技术选项之间的争论焦点。然而，计算 CPU 利用率的方式以及用于测试的基准会带来误导性很强的结果。

例如，常见错误是使用公共延迟测试或消息速率测试确定 CPU 利用率；然而，这些测试通常需要 CPU 频繁查找数据（即轮询内存中的数据），这就使得CPU看起来像是处于 100% 利用率，而实际上它完全没有工作。使用此类测试确定 CPU 利用率会产生虚假的结果。因为现实中，CPU 并不会频繁检查数据。

那么，测量 CPU 利用率的正确方式究竟是什么？在理想条件下，可使用数据带宽测试或不借助数据轮询的其他测试确定CPU利用率。或者，如果使用消息速率测试，则必须将此测试配置为避免陷入数据轮询循环，这样才能产生真实的结果。最终，最佳的选择是将实际执行的CPU指令数与测试持续期间可能已执行的 CPU 指令数进行比较。这样会得出准确的 CPU利用率百分比。

我们需要考虑的另一个重要因素是正在测量的开销类型。例如，如果测试设计为测量网络协议对 CPU利用率的影响，则应该仅测试在两台服务器之间传输的数据，而不包括额外的开销，如位于软件层中的MPI。如果目标是测量软件框架的开销，如MPI，则应使用MPI测试，但在此案例中，必须使用具备适当卸载功能的正确MPI（如果存在的话）。并不是所有的 MPI 都支持各种基于硬件的卸载，因此知晓测试的条件非常重要。

现在我们已了解如何精确地测量CPU利用率，那么剩下的问题就是：“哪种技术更为合适，卸载还是加载？”

我们在多台服务器之间进行了多次数据吞吐量测试，这些服务器分别通过EDR InfiniBand 和专有的Omni-Path 连接在一起。这些测试包括在测量 CPU 利用率时以每个互连支持的最大数据速率（大约 100 Gb/s）发送/接收传输的数据（参见表 1）。在数据速率为100 Gb/s的情况下，InfiniBand的 CPU 利用率仅为 0.8%，而为了执行相同的任务，Omni-Path的 CPU 利用率需要达到 59%。因此，在使用InfiniBand 时，CPU 对于应用程序的可用性是 99.2%；而在使用Omni-Path 时，仅有 40.4%的 CPU 周期可提供给应用程序。此外，我们在每种情况下都测量了 CPU 频率，因为 CPU 在不需要全速执行时会降低其频率以实现节能。在使用InfiniBand 时，CPU 频率能够降到其正常频率的 59%以实现节能。而在使用Omni-Path 时，CPU 全速执行，因此无法实现节能。

表 1 —— CPU 利用率比较：InfiniBand vs. Omni-Path

我们采用Intel 的Performance Counter Monitor 工具集检查 CPU 状态。该工具提供一组更丰富的测量方式来确定详细的系统状态。利用此工具，我们发现Omni-Path 的速度实际上未达到 100 Gb/s，而是稍低，为 95 Gb/s。AFREQ 状态报告在测试期间动态设置的 CPU 频率。我们还能够查看每个不同互连协议使用的迭代次数和活动周期数（参见表 2）。

表 2 —— Intel Performance Counter Monitor 工具统计数据对比

此外，在协同设计架构内的智能设备上部署InfiniBand 时，该产品还可通过卸载 MPI 操作来进一步减少 CPU 的开销。当然，为完成此次计算，测试必须确定在基准中包括软件层，这样才能获得准确的现实结果。我们计划未来进一步在不同的应用程序层面上执行多种测试，以证明InfiniBand的重大优势。

InfiniBand采用卸载技术，以降低 CPU 的负载，而最终的测试结果也正如我们所预料。如果其他测试结果与此处所示不同，则有必要调查测试环境，以更好地理解如何获得正确的结果。这些结果很有可能产生误导，无法准确反映现实的情况。（文/Mellanox公司市场部副总裁Gilad Shainer）

原文发布时间为：2016年7月5日

本文来自云栖社区合作伙伴至顶网，了解相关信息可以关注至顶网。

2.2.2操作系统（CPU利用率 系统吞吐量 周转时间 调度算法 FCFS SJF HRRN） 调度算法的评价指标 ​1.CPU利用率 2.系统吞吐量 3.周转时间 4.等待时间 5.响应时间 1.先来先服务（FCFS, First Come First Serve） 2.短作业优先（SJF, Shortest Job First） ​注意几个小细节： 对FCFS和SJF两种算法的思考… 3.高响应比优先（HRRN, Highest Response Ratio Next） 知识回顾与重要考点
CPU 利用率从 10% 提升至 60%：中型企业云原生成本优化实战指南 在互联网早期迅速发展时，相关领域企业更多注重于扩展业务，为了迅速占领市场，往往会投入较高的成本。然而，随着互联网人口红利逐渐消退，以及近几年的疫情影响，越来越多企业开始重视成本管理，从“粗放式经营”转变为“精细化运营”模式，成本优化成为企业重点关注事项。
Sentinel在docker中获取CPU利用率的一个BUG 微服务治理中限流、熔断、降级是一块非常重要的内容。目前市面上开源的组件也不是很多，简单场景可以使用Guava，复杂场景可以选用Hystrix、Sentinel。今天要说的就是Sentinel，Sentinel是一款阿里开源的产品，
HaaS100 开发调试系列 之 CPU利用率(cpuusage)的原理与使用 cpuusage（即CPU利用率，本文均用cpuusage指代CPU利用率）通常是指：CPU从事任何工作的时间比例。 如：90％的cpuusage表示CPU处于90％忙碌状态和10％空闲状态。当CPU空闲时，它什么也不做，在嵌入式实时操作系统RTOS上，它会进入idle状态，idle本身也是一个task，它只是在等待中断，消耗CPU。
在python中单线程，多线程，多进程对CPU的利用率实测以及GIL原理分析 首先关于在python中单线程，多线程，多进程对cpu的利用率实测如下： 单线程，多线程，多进程测试代码使用死循环。 1）单线程： 2）多线程： 3）多进程：