腾讯成本优化黑科技：整机CPU利用率最高提升至90%（上）-InfoQ



 写点什么

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

一、前言

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

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

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

现有混部方案如何做？问题是什么？为什么现在 CPU 利用率还是不高？
TLinux 团队的方案是如何做的？为什么要这么做？
TLinux 团队的混部方案，真实业务使用效果如何？

二、现有方案

公司内部已有的混部方案总结来讲主要有两种：

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 利用率。

三、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 利用率的目的。那么我们是怎么来做的呢？