共计 5229 个字符，预计需要花费 14 分钟才能阅读完成。
作者：常怀鑫、丁天琛
** 让人厌恶的 CPU 限流影响容器运行，有时人们不得不就义容器部署密度来防止 CPU 限流呈现。咱们设计的 CPU Burst 技术既能保障容器运行服务质量，又不升高容器部署密度。CPU Burst 个性已合入 Linux 5.14，Anolis OS 8.2、Alibaba Cloud Linux2、Alibaba Cloud Linux3 也都反对 CPU Burst 个性。
在 K8s 容器调度中，容器的 CPU 资源下限是由 CPU limits 参数指定。设置 CPU 资源下限能够限度个别容器耗费过多的 CPU 运行工夫，并确保其余容器拿到足够的 CPU 资源。CPU limits 限度在 Linux 内核中是用 CPU Bandwidth Controller 实现的，它通过 CPU 限流限度 cgroup 的资源耗费。所以当一个容器中的过程应用了超过 CPU limits 的资源的时候，这些过程就会被 CPU 限流，他们应用的 CPU 工夫就会受到限制，过程中一些要害的提早指标就会变差。
面对这种状况，咱们应该怎么办呢？个别状况下，咱们会联合这个容器日常峰值的 CPU 利用率并乘以一个绝对平安的系数来设置这个容器的 CPU limits，这样咱们既能够防止容器因为限流而导致的服务质量变差，同时也能够兼顾 CPU 资源的利用。举个简略的例子，咱们有一个容器，他日常峰值的 CPU 使用率在 250% 左右，那么咱们就把容器 CPU limits 设置到 400% 来保障容器服务质量，此时容器的 CPU 利用率是 62.5%（250%/400%）。
然而生存真的那么美妙吗？显然不是！CPU 限流的呈现比预期频繁了很多。怎么办？仿佛看上去咱们只能持续调大 CPU limits 来解决这个问题。很多时候，当容器的 CPU limits 被放大 5~10 倍的时候，这个容器的服务质量才失去了比拟好的保障，相应的这时容器的总 CPU 利用率只有 10%~20%。所以为了应答可能的容器 CPU 应用顶峰，容器的部署密度必须大大降低。
历史上人们在 CPU Bandwidth Controller 中修复了一些 BUG 导致的 CPU 限流问题，咱们发现以后非预期限流是因为 100ms 级别 CPU 突发应用引起，并且提出 CPU Burst 技术容许肯定的 CPU 突发应用，防止均匀 CPU 利用率低于限度时的 CPU 限流。在云计算场景中，CPU Burst 技术的价值有：
- 不进步 CPU 配置的前提下改善 CPU 资源服务质量；
- 容许资源所有者不就义资源服务质量升高 CPU 资源配置，晋升 CPU 资源利用率；
- 升高资源老本（TCO，Total Cost of Ownership）。
你看到的 CPU 利用率不是全副假相
秒级 CPU 利用率不能反映 Bandwidth Controller 工作的 100ms 级别 CPU 应用状况，是导致非预期 CPU 限流呈现的起因。
Bandwidth Controller 实用于 CFS 工作，用 period 和 quota 治理 cgroup 的 CPU 工夫耗费。若 cgroup 的 period 是 100ms quota 是 50ms，cgroup 的过程每 100ms 周期内最多应用 50ms CPU 工夫。当 100ms 周期的 CPU 应用超过 50ms 时过程会被限流，cgroup 的 CPU 应用被限度到 50%。
CPU 利用率是一段时间内 CPU 应用的均匀，以较粗的粒度统计 CPU 的应用需要，CPU 利用率趋势稳固；当察看的粒度变细，CPU 应用的突发特色更显著。以 1s 粒度和 100ms 粒度同时观测容器负载运行，当观测粒度是 1s 时 CPU 利用率的秒级均匀在 250% 左右，而在 Bandwidth Controller 工作的 100ms 级别观测 CPU 利用率的峰值曾经冲破 400%。
依据秒级察看到的 CPU 利用率 250% 设置容器 quota 和 period 别离为 400ms 和 100ms，容器过程的细粒度突发被 Bandwidth Controller 限流，容器过程的 CPU 应用受到影响。
如何改善
咱们用 CPU Burst 技术来满足这种细粒度 CPU 突发需要，在传统的 CPU Bandwidth Controller quota 和 period 根底上引入 burst 的概念。当容器的 CPU 应用低于 quota 时，可用于突发的 burst 资源累积下来；当容器的 CPU 应用超过 quota，容许应用累积的 burst 资源。最终达到的成果是将容器更长时间的均匀 CPU 耗费限度在 quota 范畴内，容许短时间内的 CPU 应用超过其 quota。
如果用 Bandwidth Controller 算法来治理休假，假期治理的周期（period）是一年，一年里假期的额度是 quota，有了 CPU Burst 技术之后往年修不完的假期能够放到当前来休了。
在容器场景中应用 CPU Burst 之后，测试容器的服务质量显著晋升。察看到 RT 均值降落 68%（从 30+ms 降落到 9.6ms）；99% RT 降落 94.5%（从 500+ms 降落到 27.37ms）。
CPU Bandwidth Controller 的保障
应用 CPU Bandwidth Controller 能够防止某些过程耗费过多 CPU 工夫，并确保所有须要 CPU 的过程都拿到足够的 CPU 工夫。之所以有这样好的稳定性保障，是因为当 Bandwidth Controller 设置满足下述状况时，
有如下的调度稳定性束缚：
其中，
是第 i 个 cgroup 的 quota，是一个 period 内该 cgroup 的 CPU 需要。Bandwidth Controller 对每个周期别离做 CPU 工夫统计，调度稳定性束缚保障在一个 period 内提交的全副工作都能在该周期内解决完；对每个 CPU cgroup 而言，这意味着任何时候提交的工作都能在一个 period 内执行完，即工作实时性束缚：
不论工作优先级如何，最坏状况下工作执行工夫（WCET, Worst-Case Execution Time）不超过一个 period。
如果继续呈现
调度器稳定性被突破，在每个 period 都有工作积攒下来，新提交的作业执行工夫一直减少。
应用 CPU Burst 的影响
出于改善服务质量的须要，咱们应用 CPU Burst 容许突发的 CPU 应用之后，对调度器的稳定性产生什么影响？答案是当多个 cgroup 同时突发应用 CPU，调度器稳定性束缚和工作实时性保障有可能被突破。这时候两个束缚失去保障的概率是要害，如果两个束缚失去保障的概率很高，对大多数周期来工作实时性都失去保障，能够放心大胆应用 CPU Burst；如果工作实时性失去保障的概率很低，这时候要改善服务质量不能间接应用 CPU Burst，应该先升高部署密度进步 CPU 资源配置。
于是下一个关怀的问题是，怎么计算特定场景下两个束缚被突破的概率。
评估影响大小
定量计算能够定义成经典的排队论问题，并且用蒙特卡洛模仿办法求解。定量计算的结果表明，判断以后场景是否能够应用 CPU Burst 的次要影响因素是均匀 CPU 利用率和 cgroup 数目。CPU 利用率越低，或者 cgroup 数目越多，两个束缚越不容易被突破能够放心使用 CPU Burst。反之如果 CPU 利用率很高或者 cgroup 数目较少，要打消 CPU 限流对过程执行的影响，应该升高部署进步配置再应用 CPU Burst。
问题定义是：一共有 m 个 cgroup，每个 cgroup 的 quota 限度为 1/m，每个 cgroup 在每个周期产生的计算需要（CPU 利用率）遵从某个具体散布，这些散布是互相独立的。假如工作在每个周期的开始达到，如果该周期内的 CPU 需要超过 100%，以后周期工作 WCET 超过 1 个 period，超过的局部累积下来和下个周期新产生的 CPU 需要一起在下个需要解决。输出是 cgroup 的数目 m 和每个 CPU 需要满足的具体散布，输入是每个周期完结 WCET > period 的概率和 WCET 冀望。
以输出的 CPU 需要为帕累托散布、m=10/20/30 的后果为例进行阐明。抉择帕累托散布进行阐明的起因是它产生比拟多的长尾 CPU 突发应用，容易产生较大影响。表格中数据项的格局为
其中
越靠近 1 越好，
概率越低越好。
后果跟直觉是吻合的。一方面，CPU 需要（CPU 利用率）越高，CPU 突发越容易突破稳定性束缚，造成工作 WCET 冀望变长。另一方面，CPU 需要独立散布的 cgroup 数目越多，它们同时产生 CPU 突发需要的可能性越低，调度器稳定性束缚越容易放弃，WCET 的冀望越靠近 1 个 period。
场景和参数设定
咱们设定整个零碎存在 m 个 cgroup，每个 cgroup 偏心瓜分总量为 100% 的 CPU 资源，即 quota=1/m。每个 cgoup 按雷同法则（独立同散布）产生计算需要并交给 CPU 执行。\
咱们参考排队论的模型，将每个 cgroup 视为一位顾客，CPU 即为服务台，每位顾客的服务工夫受到 quota 的限度。为了简化模型，咱们离散化地定义所有顾客的达到工夫距离为常数，而后在该距离内 CPU 最多能服务 100% 的计算需要，这个工夫距离即为一个周期。
而后咱们须要定义每位顾客在一个周期内的服务工夫。咱们假设顾客产生的计算需要是独立同散布的，其平均值是本身 quota 的 u_avg 倍。顾客在每个周期得不到满足的计算需要会始终累积，它每个周期向服务台提交的服务工夫取决于它本身的计算需要和零碎容许的最大 CPU time（即其 quota 加上之前周期累积的 token）。
最初，CPU Burst 技术中有一项可调参数 buffer，示意容许累积的 token 下限。它决定了每个 cgroup 的刹时突发能力，咱们将其大小用 quota 的 b 倍示意。
咱们对上述定义的参数作出了如下设置：
负指数分布是排队论模型中最常见、最多被应用的散布之一。其密度函数为
其中
帕累托散布是计算机调度零碎中比拟常见的散布，且它可能模拟出较大的提早长尾，从而体现 CPU Burst 的成果。其密度函数为：
为了克制尾部的概率分布使其不至于过于夸大，咱们设置了：
此时当 u_avg=30% 时可能产生的最大计算需要约为 500%。
数据展现
按上述参数设置进行蒙特卡洛模仿的后果如下所示。咱们将第一张（WCET 冀望）的图表 y 轴进行颠倒来更好地合乎直觉。同样地，第二张图表（WCET 等于 1 的概率）示意调度的实时性失去保障的概率，以百分制示意。
负指数分布
帕累托散布
论断
一般来说，u_avg（计算需要的负荷）越高，m（cgroup 数量）越少，WCET 越大。前者是显然的论断，后者是因为独立同散布状况下工作数量越多，整体产生需要越趋于均匀，超出 quota 需要的工作和低于 quota 从而空出 cpu 工夫的工作更容易互补。
进步 buffer 会使得 CPU Burst 施展更好的成果，对单个工作的优化收益更显著；但同时也会增大 WCET，意味着减少对相邻工作的烦扰。这也是合乎直觉的论断。
在设置 buffer 大小时，咱们倡议依据具体业务场景的计算需要（包含散布和均值）和容器数量，以及本身需要来决定。如果心愿减少整体零碎的吞吐量，以及在均匀负荷不高的状况下优化容器性能，能够增大 buffer；反之如果心愿保障调度的稳定性和公平性，在整体负荷较高的状况下缩小容器受到的影响，能够适当减小 buffer。
一般而言，在低于 70% 均匀 CPU 利用率的场景中，CPU Burst 不会对相邻容器造成较大影响。
模仿工具与应用办法
说完了干燥的数据和论断，接下来介绍可能有许多读者关怀的问题：CPU Burst 会不会对我的理论业务场景造成影响？为了解决这个纳闷，咱们将蒙特卡洛模仿办法所用工具稍加革新，从而能帮忙大家在本人的理论场景中测试具体的影响～
工具能够在这里获取：https://codeup.openanolis.cn/…
具体的应用阐明也附在 README 中了，上面让咱们看一个具体的例子吧。
小 A 想在他的服务器上部署 10 台容器用于雷同业务。为了获取精确的测量数据，他先启动了一台容器失常运行业务，绑定到名为 cg1 的 cgroup 中，不设限流以获取该业务的实在体现。
而后调用 sample.py 进行数据采集：（演示成果只采集了 1000 次，理论倡议有条件的状况下采集次数越大越好）
这些数据被存储到了./data/cg1_data.npy 中。最初输入的提醒阐明该业务均匀占用了约 6.5% 的 CPU，部署 10 台容器的状况下总的均匀 CPU 利用率约为 65%。（PS：方差数据同样打印进去作为参考，兴许方差越大，越能从 CPU Burst 中受害哦）
接下来，他利用 simu_from_data.py 计算配置 10 个 和 cg1 雷同场景的 cgroup 时，将 buffer 设置为 200% 的影响：
依据模仿后果，开启 CPU Burst 性能对该业务场景下的容器简直没有负面影响，小 A 能够放心使用啦。
想要进一步理解该工具的用法，或是出于对实践的趣味去扭转散布查看模仿后果，都能够拜访下面的仓库链接找到答案～
对于作者
常怀鑫（一斋），阿里云内核组工程师，善于 CPU 调度畛域。
丁天琛（鹰羽），2021 年退出阿里云内核组，目前在调度畛域等方面学习钻研。
点击 此处，即可查看阿里云专有云麻利版云原生 Stack 相干介绍！
