阿八博客
  • 100000+

    文章

  • 23

    评论

  • 20

    友链

  • 最近新加了很多技术文章,大家多来逛逛吧~~~~
  • 喜欢这个网站的朋友可以加一下QQ群,我们一起交流技术。

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

欢迎来到阿八个人博客网站。本 阿八个人博客 网站提供最新的站长新闻,各种互联网资讯。 喜欢本站的朋友可以收藏本站,或者加QQ:我们大家一起来交流技术! URL链接:https://www.abboke.com/jsh/2019/1010/116511.html

作者:腾讯TLinux团队

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

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

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

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

现有混部方案如何做?问题是什么?为什么现在CPU利用率还是不高?
TLinux团队的方案是如何做的?为什么要这么做?
TLinux团队的混部方案,真实业务使用效果如何?
二、现有方案
公司内部已有的混部方案总结来讲主要有两种:

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

cgroup方案
同时,cgroup方案还有一些他自身方案带来的问题,比如说period/quota控制需要遍历整个cgroup树影响性能问题,quota太小导致整机死锁问题

3.现有方案概括
除了上述两种方案,在业务层面的调度层,有的业务也做了一些工作,比如说根据机器以往的CPU使用情况,在该机器CPU利用率的时候,从集群中其他机器上调度离线过来运行
这同样也会有问题,比如业务突发流量如何即使处理不影响在线?在线虽然占CPU低,但是延迟敏感,还是无法运行离线的问题

总结起来,现有的混部方案在改善CPU利用率低下问题上,在某些场景有一定效果
但是现有方案对问题的改善有限,并且在很多对延迟敏感性的业务场景,使用现有方案是无法混部的
因为,现有混部方案都无法解决一个核心问题,就是如何做到让离线不影响在线的问题
而导致离线业务影响在线业务的原因就是,在线需要CPU的时候并不能及时抢占离线
TLinux团队的方案解决了这个问题,并且做了很多优化,目的是在离线不影响在线之后,让离线能够见缝插针的利用空闲CPU,提升整机CPU利用率

三、TLinux团队的混部方案
1.方案框架
TLinux团队混部方案在内核层面对离在线混部提供支持,从功能将主要包括,离线调度类支持,负载均衡优化,带宽限制,用户接口提供
我们提供了离线专用调度类,专为离线进程设计
并且对负载均衡做了深入的优化,从而达到提升整机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上运行

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

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


业务场景A(a模块)混部前后性能对比
在B测试场景中(模块b是一个翻译模块,对时延很敏感),原本b模块是不能混部的,业务尝试过混部,但是因为离线混部上去之后对模块b的影响很大,时延变长,所以一直不能混部
使用我们的方案的效果如下图所示,整机CPU利用率从20%提升至50%,并且对模块没有影响,时延基本上没有变化


业务场景B(b模块)混部前后性能对比
模块C对时延不像场景A,B那么敏感,所以在使用我们提供的方案之前,利用cgroup方案进行混部,CPU最高可以达到40%
但是平台不再敢往上压,因为再往上压就会影响到在线c业务
如下图所示,使用我们的方案之后,平台不断往机器上添加离线业务,将机器CPU压至90%的情况下,c业务的各项指标还是正常,并没有受到影响

相关文章

暂住......别动,不想说点什么吗?
  • 全部评论(0
    还没有评论,快来抢沙发吧!