腾讯成本优化黑科技：整机CPU利用率最高提高至90%

做者：腾讯TLinux团队

导语：腾讯TLinux团队提出了一套全新的混部方案，在不影响在线业务的前提下，对整机CPU利用率提高效果很是明显，在有的业务场景下，整机CPU利用率甚至能提高至90%。

1、前言
腾讯运营着海量的服务器，且近年的增加有加速的趋势，成本问题日益严峻。其中，CPU利用率不高一直是影响整机效率的短板。试想一下，若是能让整机的CPU利用率翻一翻，是什么概念？这至关于把一台机器当两台使用，能为公司节省巨额的成本开销。所以，各BG各业务都在想办法提高整机CPU利用率。你们尝试让各类业务混部，试图达到提升整机CPU利用率的目的。然而，方案的实际效果却不尽如人意。现有的混部方案始终没法作到离线业务不影响在线，这种影响直接致使多数业务没有办法混部。

基于现状以及业务的需求，TLinux团队提出了一套全新的混部方案，该方案已在公司不少业务中获得了普遍的验证，在不影响在线业务的前提下，对整机CPU利用率提高效果很是明显，在有的业务场景下，整机CPU利用率甚至能提高至90%。

本文将围绕如何提高整机CPU利用率这个问题来展开，重点关注如下三个问题：

现有混部方案如何作？问题是什么？为何如今CPU利用率仍是不高？
TLinux团队的方案是如何作的？为何要这么作？
TLinux团队的混部方案，真实业务使用效果如何？
2、现有方案
公司内部已有的混部方案总结来说主要有两种：

Cpuset方案
Cgroup方案
1.cpuset方案
既然担忧离线在线在相同的CPU上互相影响，那么把在线&离线业务直接隔离开是最容易想到的方案，这就是cpuset方案，具体作法以下图所示：

cpuset方案
在线业务限定在某些核上，离线业务限定在某些核上面。这种作法，在某些场景下，是有效果的，由于从物理上将离在线隔离开了，他们之间互不影响（超线程，cache互相影响这里不展开细说）。可是这种方案实用性不强，好比在多线程的业务场景，须要利用多核优点，若是将在线限定到少数几个核就会影响性能。而且，这种方案并无真正的达到混部的效果，在在线的那些核上，仍是没有办法混部离线业务。

2.cgroup方案
Cgroup方案，就是利用cgroup提供的share以及period/quota功能来实现。Share是经过给不一样的cgruop配置权重来达到控制不一样cgroup CPU占用时间的目的。period/quota是能够控制单位时间内某个cgroup占用CPU的时间。你们想经过这两种功能，来控制离线调度组的占用CPU时间。这种方案在那种对时延不敏感的业务上，有必定效果。可是，不管是share仍是period/quota，都没有办法解决一个问题，就是在线没法及时抢占离线的问题。从而在延迟敏感的业务场景，使用group方案会致使在线受影响，业务没法混部。

cgroup方案
同时，cgroup方案还有一些他自身方案带来的问题，好比说period/quota控制须要遍历整个cgroup树影响性能问题，quota过小致使整机死锁问题。

3.现有方案归纳
除了上述两种方案，在业务层面的调度层，有的业务也作了一些工做，好比说根据机器以往的CPU使用状况，在该机器CPU利用率的时候，从集群中其余机器上调度离线过来运行。这一样也会有问题，好比业务突发流量如何即便处理不影响在线？在线虽然占CPU低，可是延迟敏感，仍是没法运行离线的问题。

总结起来，现有的混部方案在改善CPU利用率低下问题上，在某些场景有必定效果。可是现有方案对问题的改善有限，而且在不少对延迟敏感性的业务场景，使用现有方案是没法混部的。由于，现有混部方案都没法解决一个核心问题，就是如何作到让离线不影响在线的问题。而致使离线业务影响在线业务的缘由就是，在线须要CPU的时候并不能及时抢占离线。TLinux团队的方案解决了这个问题，而且作了不少优化，目的是在离线不影响在线以后，让离线可以见缝插针的利用空闲CPU，提高整机CPU利用率。

3、TLinux团队的混部方案
1.方案框架
TLinux团队混部方案在内核层面对离在线混部提供支持，从功能将主要包括，离线调度类支持，负载均衡优化，带宽限制，用户接口提供。咱们提供了离线专用调度类，专为离线进程设计。而且对负载均衡作了深刻的优化，从而达到提高整机CPU利用率的目的。另外，为了业务更加方便的使用该方案，咱们还为业务提供了完善的离线进程设置控制接口。

TLinux团队混部方案框架
方案中最重要的两个问题是：

如何让在线及时抢占离线？
如何让离线高效的利用空闲CPU？
以下图所示，为了解决在线抢占离线不及时的问题，咱们专门为离线设计了离线专用调度类，为了让离线更好的利用空闲CPU，咱们对负载均衡作了大量的优化，下面就一个一个来细说。

方案概览图
2.如何让在线及时抢占离线？
在说明这个问题解决以前，咱们先来分析一下，为何现有的混部方案没办法作到及时抢占。

抢占逻辑，以下图所致，在同调度类优先级的进程，互相抢占的时候，须要知足两个条件。第一个是抢占进程的虚拟时间要小于被抢占进程，第二是被抢占进程已经运行的实际要大于最小运行时间。若是两个条件不能同时知足，就会致使没法抢占。如今混部方案，在线离线都是cfs，这样当在线须要CPU试图抢占离线的时候，两个条件并不必定会知足，从而就致使在线抢占不及时，这也是现有方案问题的关键。

抢占逻辑
在当时制定方案，分析清楚了现有方案的问题以后，咱们首先试图从优化抢占判断入手，当时想过不少办法，好比：对最小运行时间进行优化，当在线抢占离线的时候，忽略最小运行时间判断？

在线抢占离线
另外就是当在线抢占离线，可是在线虚拟时间更大的时候，与离线互换虚拟时间？咱们想过不少办法，有一些效果，可是仍是不能达到预期。

回过去看抢占逻辑，若是抢占的进程的调度类优先级更高的时候，是会立马抢占的。好比如今有个进程要运行，原来的CPU是空闲的，那么这个进程是会当即执行的。而实际上这里也是发生了抢占，cfs调度类抢占idle调度类。由于cfs调度类的优先级高于idle调度类的优先级。

所以，咱们试图经过给离线进程专门设置一个专用调度类，来解决抢占的问题。通过调研，咱们最终决定为离线进程新加一个调度类：offline调度类，offline调度类的优先级低于cfs调度类，高于idle调度类，所以，cfs调度类能够随时抢占offline调度类。下图是咱们为了支持离线调度类，支持的相关子系统，包括调度类基本功能支持，task_grouop支持，cpuacct, cpuset子系统支持，控制接口支持，等等。

支持离线调度类及相关子系统
在为离线单独设计了调度类解决了抢占不及时的问题以后，咱们会发现一个问题，在咱们的方案中，在线是很强势的，须要CPU的时候当即抢占，那么对离线来讲就不利。咱们的方案目标，不只要让离线不影响在线，还须要达到的目的是，要让离线可以见缝插针的把空闲的CPU给利用上，达到提高整机CPU利用率的目的。那么咱们是怎么来作的呢？

3.如何让离线高效的利用空闲CPU？
那么就来看第二个问题，离线如何高效的利用空闲CPU？ 由于当有在线的时候，离线没法得到CPU，所以要让离线高效的得到CPU，第一个须要解决的是，离线如何去感知在线剩余的算力？在线占用100%的核上，是不该该调度离线过去运行的，由于离线一直得到不了CPU。在线占用60%与在线占用10%的CPU上，应该调度不一样负载的离线去运行。

离线如何高效的利用空闲CPU？
所以，在线感知剩余算力很关键，那么怎么作的呢？咱们最开始是若是负载均衡的时候，这个核有在线在运行就不调度离线过来，此种作法比较粗糙，波动很大效果不明显。所以咱们对此进行了优化，离线算力算法以下：

(1)1-avg/T=离线负载算力

(2)avg随之T不断衰减，过一个T衰减成原来的1/2

(3)在线的运行时间不断加入avg中

直接看文字很难懂，举个例子；好比在线占用CPU100%，T=1ms

那么离线算力=1-(1/2+1/4+1/8+1/16+…)=0 ，也就是说算出来离线的算力是0，所以这个核上在线占着100%的CPU。

若是在线占用20%的CPU，T=1ms，那么离线算力=1-(0.2/2+0.2/4+0.2/8+…)=0.8，所以，能够迁移一些离线进程到这个核上。

另外，第二个是咱们引入了等待延迟，用于优化进程负载的计算。为何要引入等待时间呢？由于咱们发现，若是用原来的算法，在业务限制某个CPU不让离线运行时候，这个离线进程可能没法被调走（好比说，四个CPU，四个离线，限制一个核，按照原来算法负载是均衡的）。另外咱们在测试中发现，离线在在线混部上来以后，离线的队列等待时间会增大，缩短离线进程在队列中的等待时间，是提升离线CPU占有效率的关键。所以，咱们引入了队列等待时间，经过等待时间算出一个翻倍因子，从而在负载均衡的时候，将最应该被调度的离线进程及时调度到空CPU上运行。

4、新方案效果
目前TLinux团队混部方案的效果多个业务上都获得了验证，功能知足业务需求，在不影响在线业务的前提下，整机CPU利用率提高很是显著，超过业务预期。下面是几个典型场景的测试数据。

以下图所示，在A测试场景中，模块a一个用于统计频率的模块，对时延很是敏感。此业务不能混部，整机CPU利用率只有15%左右，业务尝试过使用cgroup方案来混部，可是cgroup方案混部以后，对在线模块a影响太大，致使错误次数陡增，所以此模块一直不能混部。使用咱们提供的方案以后，能够发现，CPU提高至60%，而且错误次数基本没有变化。

业务场景A(a模块)混部先后性能对比

业务场景A(a模块)混部先后性能对比
在B测试场景中（模块b是一个翻译模块，对时延很敏感），本来b模块是不能混部的，业务尝试过混部，可是由于离线混部上去以后对模块b的影响很大，时延变长，因此一直不能混部。使用咱们的方案的效果以下图所示，整机CPU利用率从20%提高至50%，而且对模块没有影响，时延基本上没有变化。

业务场景B（b模块）混部先后性能对比

业务场景B（b模块）混部先后性能对比
模块C对时延不像场景A，B那么敏感，因此在使用咱们提供的方案以前，利用cgroup方案进行混部，CPU最高能够达到40%。可是平台再也不敢往上压，由于再往上压就会影响到在线c业务。以下图所示，使用咱们的方案以后，平台不断往机器上添加离线业务，将机器CPU压至90%的状况下，c业务的各项指标仍是正常，并无受到影响。

业务场景C（c模块）混部先后性能对比
TLinux团队从今年三月份就开始在各业务场景中进行测试灰度，期间遇到了各类各样的问题，不断的优化完善。验证的结果是：TLinux团队混部方案在不影响在线业务的前提下，可以大幅度提高整机CPU的利用率，能为公司节省大量的运营成本。目前TLinux团队提供的公司内部内核，已经彻底支持TLinux团队混部方案，公司不少业务已经开始使用TLinux团队提供的混部方案。

PS：TLinux 团队承载了腾讯公司级的服务器操做系统、内核、发行版及虚拟化研发任务，专一解决TLinux系统、内核、网络、虚拟化平台及文件系统的问题。在历次的考验中，承受住了服务器数量飙升的压力，为腾讯提供了稳定、持久的服务。