腾讯 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 利用率的目的。那么我们是怎么来做的呢?
评论 1 条评论