专栏首页腾讯大讲堂的专栏云原生下,TencentOS “如意” CPU QoS之绝对抢占

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

前言

上篇《减少碳排放上万吨是什么样的高科技?》结合腾讯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>

其中,

Δ:为单次运行时长

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)。

上图中,绿色为在线容器单独运行时的调度延迟数据,红色为在线容器和离线容器同时运行时在线容器的调度延迟数据。可以看到,采用传统的CFS调度方式,在存在干扰的情况下,在线容器的平均延迟和最大延迟都显著的增大。

实验二

在线容器和离线容器均绑定在0-7 CPU上,离线容器采用BT调度类,通过perf采集调度延时数据,分别统计平均延迟(Average Latency)和最大延迟(Max Latency)。

上图中,绿色为在线容器单独运行时的调度延迟数据,红色为在线容器和离线容器同时运行时在线容器的调度延迟数据。可以看出,离线任务采用BT调度的情况下在线容器的平均延迟和最大延迟并未发生显著变化,与单独运行时基本一致。

在微信业务A测试场景下,用于统计频率的模块a对时延非常敏感且不能混部,整机CPU利用率仅在15%左右。团队曾尝试使用cgroup方案来混部,但此方案对在线模块a影响太大,导致错误次数陡增。在使用“如意”方案之后,CPU利用率提升至60%,并且错误次数基本没有变化。

结语

腾讯TencentOS Server作为通用服务器OS,承载支撑了腾讯内外各类业务。在云原生技术不断成熟的今天,TencentOS 研发团队连续10余年不断开发打磨迭代,在稳定性、功能特性、硬件支持、安全等各方面精益求精,积极探索,更好支持对接云原生服务。

恰逢腾讯99公益日,“助力实现碳中和,环保可持续发展”,与TencentOS研发团队的“如意”混部方案“大幅提升资源利用率,节约能耗、做绿色科技”理念一脉相承,这里也打个小广告,戳下方阅读原文,请参加99公益日更多活动吧!

近期热文推荐

你“在看”我吗?

文章分享自微信公众号:
腾讯大讲堂

本文参与 腾讯云自媒体分享计划 ,欢迎热爱写作的你一起参与!

如有侵权,请联系 cloudcommunity@tencent.com 删除。
登录 后参与评论
0 条评论

相关文章

  • 腾讯TencentOS 十年云原生的迭代演进之路

    蒋彪,腾讯云高级工程师,10+年专注于操作系统相关技术,Linux内核资深发烧友。目前负责腾讯云原生OS的研发,以及OS/虚拟化的性能优化工作。

    腾讯云原生
  • 云原生下,TencentOS“如意” IO隔离之BPS. IOPS. 权重隔离

    架构鹅结合TencentOS团队在混部方面的落地实战经验,重点推送了TencentOS Server大规模容器集群混部服务器QoS产品“如意”相关内容。

    腾讯 架构师
  • 腾讯为什么也做操作系统?

    01 提到操作系统,你想到的是? 提到“操作系统”这个词,大家都会蹦出一堆词Windows、macOS、Linux、iOS、Android安卓、Harmony...

    腾讯大讲堂
  • 三个时代,一个未来 | 腾讯操作系统TencentOS创新之路

    网络信息产业中,芯片被比喻为心脏,操作系统被认为是计算机的灵魂。二十年来,国内信息产业始终在“缺芯少魂”的困境中,中国在高端芯片行业缺乏自主创新能力,国产操作系...

    腾讯 架构师
  • 混部之殇-论云原生资源隔离技术之CPU隔离(一)

    蒋彪,腾讯云高级工程师,10+年专注于操作系统相关技术,Linux内核资深发烧友。目前负责腾讯云原生OS的研发,以及OS/虚拟化的性能优化工作。 导语 混部...

    腾讯云原生
  • 内存回收导致关键业务抖动案例分析-论云原生OS内存QoS保障

    蒋彪,腾讯云高级工程师,10+年专注于操作系统相关技术,Linux内核资深发烧友。目前负责腾讯云原生OS的研发,以及OS/虚拟化的性能优化工作。 导语 云原生...

    腾讯云原生
  • CVTE2017秋季校招一面回忆(C++后台岗)

    2016.9.9日下午再一次参加了CVTE的C++后台开发岗的面试,面试经历了1个小时20分钟左右的时间,被问及了很多问题,很多问题也没有回答出来,自己还是存在...

    Dabelv
  • 视频直播| 基础原理篇

    進无尽
  • 如何快速的开发一个完整的直播购物源码,基础篇

    大半年没写博客了,但我一直关注着互联网的动向,最近会研究很多东西,并分享,今年移动直播行业的兴起,诞生了一大批网红,甚至明星也开始直播了,因此不得不跟上时代的步...

    云豹kj的晨曦
  • 2分31秒,腾讯云创造128卡训练ImageNet新记录

    基于腾讯公有云25Gbps的VPC网络环境,使用128块V100,借助Light大规模分布式多机多卡训练框架,在2分31秒内训练 ImageNet 28个epo...

    新智元
  • 性能之殇:从冯·诺依曼瓶颈谈起

    电子计算机与信息技术是最近几十年人类科技发展最快的领域,无可争议地改变了每个人的生活:从生活方式到战争方式,从烹饪方式到国家治理方式,都被计算机和信息技术彻底地...

    机器之心
  • 指令集架构(ISA)之IBM Power ISA开源应对​RISC-V生态(13k字)

    科学Sciences导读:指令集架构(Instruction-SetArchitecture, ISA)之IBM Power ISA开源应对RISC-V生态。本...

    秦陇纪
  • 锁的使用以及底层原理

    我们知道,@synchronized是一把互斥锁(互斥锁保证在任何时刻都只能有一个线程访问该对象),它通过大括号来作为加锁、解锁的标识。

    拉维
  • 重磅:人工智能产业深度研究报告

    大数据文摘
  • 刀尖上的舞蹈?股票Alpha模型与机器学习

    在开发股票投资模型这项工作中,很少有凭空搭建的楼阁。尽管可以使用机器学习类的工具增强模型性能,但是大部分模型的基础结构,依然基于传统的资产定价模型和因子分析演化...

    量化投资与机器学习微信公众号
  • 中国亟待攻克的“卡脖子”技术清单

    “不锈钢能不能不生锈?”这个有点黑色幽默的问题,几乎让中国航天科技集团六院发动机专家、长征五号运载火箭副总设计师陈建华落下心病。

    钱塘数据
  • Hadoop(HDFS+MapReduce+Hive+数仓基础概念)学习笔记(自用)

    文件中有两个配置,删除其中任意一个,修改剩下的一个配置将address改为系统新分配的mac地址,将NAME改成eth0,保存退出

    ChinaManor
  • 美国工程院士、谷歌首席架构师、结对编程榜样杰夫·迪恩(JeffDean)博士传记(27k字)

    关键词:杰夫·迪恩(Jeff Dean),杰弗里·阿德盖特·迪恩(Jeffrey Adgate Dean),简历(Resume),博士(Doctor),谷歌人(...

    秦陇纪
  • [日常] 面试知识点总结(持续更新)

    陶士涵

扫码关注云+社区

领取腾讯云代金券