云原生下，TencentOS “如意” CPU QoS之绝对抢占

腾讯大讲堂

发布于 2021-09-14 10:10:11

2.4K1

发布于 2021-09-14 10:10:11

前言

上篇《减少碳排放上万吨是什么样的高科技？》结合腾讯TencentOS团队在混部方面的落地实战经验，重点介绍混部概念以及TencentOS Server大规模容器集群混部服务器QoS产品“如意”。

“如意”最大实现了动态的资源调度和抢占，空闲时高优先级容器借资源借给低优先级容器使用，需要时再快速抢回来，整个过程在服务器内部完成，容器集群调度层面无需感知和干预，真正做到了提升资源利用率和业务隔离的统一，CPU利用率也从混部前的15%提升到现在45%左右，可使上万台服务器节省电能近2亿度，相当于减少碳排放7万吨。

本篇将针对“如意”特性中CPU QoS（Quality of Service，服务质量）绝对抢占的部分进行分析，阐述如何通过腾讯云原生内核自行研发的离线调度器——BT调度进行任务优化和提升，实现并保障云原生场景下的高质量服务。

背景

2018年云原生兴起，用户可以采用更弹性灵活的方式去部署自己的服务，各式各样的应用在云平台上百花齐放，同时也对平台和系统提出了更高的要求。

云原生应用的技术基础为基础设施即服务(IaaS)、平台即服务(PaaS)、软件即服务(SaaS)。

而从底层视角来梳理下操作系统运行中，不同优先级业务时所遇到的问题与挑战。

通常，一台服务器上会运行着多个容器对应上层不同的业务，而业务之间的优先级也不尽相同，有面向终端客户的交互式业务，有偏向后台的计算存储型的业务，操作系统需要合理的调度不同种类的业务，来保证服务的质量和系统整体的吞吐率。

在实际的生产环境中，常常会遇到高优先级业务和低优先级业务的进程运行在同一个CPU上。

而高低优先级是针对业务逻辑本身定义的，就内核执行的两个进程，如果未做特殊的设置，内核就会平等的调度两个进程，很容易发生高优先级进程被低优先级进程干扰，造成服务的抖动进而影响用户体验，这显然不是业务想要的。

CFS中的优先级与“公平”一定合理吗？

关于调度，首先说内核当前默认的CFS (Completely Fair Scheduler) 调度器。为区别不同优先级的进程，CFS提供nice值的配置，用户可以通过为进程设置nice值来调节进程的调度优先级，nice值的范围为[-20, 19]，默认值为0，值越小优先级越高。

因此，通常给低优先级进程指定一个 19 nice值，这样高优进程就会比低优进程优先获得更多的CPU运行时间，但这样真的能解决干扰的问题？

上图为两个死循环脚本的执行情况，我们将二者都绑定到6号CPU上运行，其中high_prio_loop进程的nice值为0，而low_prio_loop的nice值为19，可以看到此时高优进程确实比低优进程获得了更多的CPU时间，但是同时低优进程仍然获得了1.3%的CPU时间，这意味着在低优进程执行的这段时间内，高优进程无法第一时间得到调度，也就造成低优进程对高优进程的干扰。

那么，CFS能否做到高优进程对低优进程的绝对抢占，即当高优进程要运行时，总能无条件在第一时间抢占低优进程？就当前的内核CFS代码来看，恐怕很难，CFS能最大程度的提高高优进程抢占低优进程的“概率”，而无法做到绝对的抢占，这涉及到了CFS调度算法的核心调度逻辑，接下来我们看看为什么说CFS无法实现绝对的抢占。

CFS调度策略在选择任务执行时的基本逻辑很简单，一般情况就是选择位于运行队列 (run queue) 上的第一个任务。在运行队列中，各个任务按照 vruntime 值的大小从小到大排列，即vruntime越小的进程，越靠近队首。由于任务的调度实体 (sched_entity) 会频繁地进出运行队列，因此运行队列中任务的调度实体按照红黑树方式进行组织。

当进程得到调度并运行时，其vruntime就会根据单次运行时长进行累加，另外，为了支持进程优先级，CFS在vruntime的累加时长上引入了 权重 (weight) 的概念，因此vruntime的计算公式如下：

vruntime = vruntime_{old} + \Delta t\times \frac {1024}{weight}

<br>vruntime=vruntimeold+Δt×weight1024<br>

其中，

Δt ：为单次运行时长

weight：为进程权重

从上述公式中可以看出，权重越大的进程，单位时间内其vruntime增长的“越慢”，而权重越小的进程，单位时间内其vruntime增长的“越快”。

例如，当运行实际时长为1ms，即1000000ns时，一个权重为1024的进程vruntime的增量为1000000，而一个权重为335的进程vruntime增量约为3000000。不难看出，权重1024的进程运行3ms所累加的vruntime增量与权重335进程运行1ms所累加的vruntime相同，即权重1024进程的运行时间与权重335进程的运行时间存在3:1的关系，如果二者皆为CPU利用率100%的死循环程序，那么当二者绑定到同一个CPU上运行的时候，将会出现75%：25%。

用户层面所设置的nice值，反应到内核层面，就是权重值，即nice与进程权重存在一个一一映射的关系。

通过上面的映射关系可以得出，nice值为默认的0时对应的权重为1024，nice值为5时对应的权重为335，因此，简单验证，设置两个进程的nice值分别为0和5，正如之前所计算的，呈现除了75%：25%的CPU比例划分。

当得出CFS对于vruntime的计算方式之后，CFS对于进程优先级的支持，是基于vruntime的增量比例控制上的，但不管如何偏袒高优进程，缩小其vruntime增量，只要进程运行，在当前CPU上，vruntime毫无疑问是单调递增的。而低优进程虽然大部分时间得不到调度执行，但是只要不执行，其vruntime将不会改变，总有一个时间点，高优任务的vruntime会超过低优任务的vruntime从而排到低优任务的后面，而下次调度的时候将会选择出vruntime更小的低优任务执行，让高优任务等待。

这就是CFS号称完全公平调度中的“公平”意义所在，只要等待足够久，低优进程总能守得云开见月明，迎来自己的高光时刻，顺利挤占高优进程夺取CPU。

CFS让高优任务占尽优势的同时，也保留了低优任务使用CPU的权利，作为一个通用的调度算法，CFS是公平也是合理的。但当我们再次回到真实的生产环境中，重新思考，一个高优任务在运行时必须一定概率上被低优任务干扰吗？答案或许是否定的，因为这可能导致一个监控上的毛刺，或引发线上服务的抖动，继而遭到用户的差评..……

而当我们要追求99.999999%的可靠性以及更高的QoS，CFS的公平对于高优进程来说，似乎又不那么“公平”了。

绝对抢占之BT调度

何为绝对抢占，即高优进程在运行时不会被低优进程挤占打断，被唤醒时能无条件抢占低优进程。

如上文中，CFS从设计理念上就不支持绝对抢占，因此，腾讯云原生内核自行研发了支持绝对抢占的离线调度器——BT调度。

我们将低优任务通常是那些对延迟不敏感的后台任务称之为离线任务，而高优任务往往直接对接用户或者线上具体业务，即在线任务。

BT调度作为一个新的调度类，位于CFS调度类和IDLE调度类之间。内核在每次执行调度决策时，会依据从上到下的顺序进行选取，如果CFS调度类中有任务，将会从中依照CFS调度算法选取一个任务调度执行，如果CFS调度类中无任务，则会轮到离线调度类中的执行任务，如果此时各大调度类无任务需要运行，则轮到IDLE调度类，让CPU休息一会。

从上图中可以看到，离线调度类所处的位置，决定了其对CFS调度类任务的“先天劣势”，一个离线任务，不管其优先级多高，只要此时有“在线的”CFS任务需要运行，内核就一定会优先执行，实现了在线任务对离线任务的绝对抢占。

关于BT调度更多的细节，请参见：腾讯成本优化黑科技：整机CPU利用率最高提升至90%

BT调度的实际效果

实验环境下，8 CPU在线容器，每CPU上的利用率约为20%，8 CPU离线容器，每CPU上的利用率约为60%。

实验一

在线容器和离线容器均绑定在0-7 CPU上，不采取额外的设置，通过perf采集调度延时数据，分别统计平均延迟(Average Latency)和最大延迟(Max Latency)。