生活宝|商城|团购|房产|招聘|外卖|交友|微博|汽车|同城|游戏|贷款|发稿|建站|软件|客服
上海论坛

2017双11技术揭秘—千亿级流量来袭,如何用硬件加速技术为CPU减负?

更新于 2017-12-29 11:27:07 510人阅读 0人回复 显示全部楼层 倒序浏览

a
0 0
  @ME:   
  • TA的每日心情
    慵懒
    昨天 11:58
  • 签到天数: 13 天

    连续签到: 1 天

    [LV.3]偶尔看看II

    发表于 2017-12-29 11:27:07 | 显示全部楼层 |阅读模式
    53快服 销量提升50%

    马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

    您需要 登录 才可以下载或查看,没有帐号?快速注册

    x

    摘要: 在刚过去的2017年双11零点流量高峰的考验下,主站接入层Tengine Gzip硬件加速机器运行平稳、同等条件下相比于未开启QAT加速的机器性能提升21%左右。

    作者:王发康(毅松)
    主站接入层是阿里2015年全站HTTPS项目诞生的产品,目前已经承载集团90%以上的入口流量。2016年主站接入层不仅在运维自动化、高可用领域取得重大突破,而且软件层面上也做过很多性能优化,促使2016年双11平稳度过。秉着软硬件结合的性能优化思想,2017年主站接入层在硬件加速领域迈出了第一步。在刚过去的2017年双11零点流量高峰的考验下,主站接入层Tengine Gzip硬件加速机器运行平稳、同等条件下相比于未开启QAT加速的机器性能提升21%左右。
    背景介绍
    众所周知,通用处理器(CPU)的摩尔定律已入暮年,而机器学习和Web服务需要的运算能力却指数级增长。随着如今硬件技术的成熟发展,普通CPU无论是在计算能力,还是资源成本上相对于一些专用加速硬件已经没有绝对优势,这也促使硬件加速技术得到各大公司的青睐,譬如三大互联网巨头百度、阿里、腾讯内部的接入层采用类似KeyLess方案来加速HTTPS的卸载,不仅提高了用户体验,还节省了机器成本。根据当前调研结果发现:目前业内各大公司接入层针对于Gzip采用硬件加速还是一片空白,阿里接入层首次结合硬件加速技术卸载Gzip不仅带来了性能提升,而且对业界在此领域的发展也有重大影响意义。
    接入层Tengine当前性能瓶颈是CPU,譬如Gzip模块在Tengine中CPU占比高达15%-20%左右,相比于其它模块CPU消耗高、占比呈增长趋势(后端应用压缩逻辑后续统一前置接入层)、且集中,所以Gzip模块使用硬件卸载对于性能提升、成本优化是不可或缺。
    分析与调研
    分析前先简单介绍下什么是硬件加速: 硬件加速(Hardware Acceleration)就是利用硬件模块来替代软件算法以充分利用硬件所固有的快速特性(硬件加速通常比软件算法的效率要高),从而达到性能提升、成本优化目的,当前主要是如下两大加速方式:
    • FPGA 现场可编程门阵列,可针对某个具体的软件算法进行定制化编程,譬如业内的智能网卡;
    • ASIC 专用集成电路,它是面向专门用途的电路、专门为一个用户设计和制造的,譬如Intel的QAT卡仅支持特定加减密、压缩算法;
      FPGA与ASIC的对比如下表格所示:
    模式
    上市速度
    性能
    一次性成本
    量产成本
    可配置

    FPGA
    周期较短
    较差(1x)
    较低
    高(100x)
    灵活

    ASIC
    周期较长
    好(4x)
    较高
    低(1x)
    有限
    接入层Tengine CPU消耗分析
    主站接入层承载集团90%以上的入口流量,看似只是作为一个七层流量转发网关,但是却做了非常之多的事情,譬如https卸载及加速、单元化、智能流量转发策略、灰度分流、限流、安全防攻击、流量镜像、链路追踪、页面打点等等,这一系列功能的背后是Tengine众多模块的支持。由于功能点比较多,所以这就导致Tengine的CPU消耗比较分散,其主流程处理如下图所示:

    各模块CPU消耗占比Top 5如下表格所示:
    模块名称
    功能介绍
    CPU占比

    Gzip
    解压缩
    15%-20%

    Sinfo
    流量镜像
    10%

    TMD
    限流
    8%

    Lua
    lua相关业务
    8%

    WAF
    防火墙
    6%
    其它众多模块 ... ...
    就当前接入层流量模型分析来看,Gzip单个模块CPU消耗占比达到15%-20%左右(注:主要是压缩消耗)且占比呈上升趋势,所以对Gzip使用硬件卸载迫在眉睫。
    加速方案调研Intel QAT卡
    QAT(Quick Assist Technology )是Intel公司推出的一种专用硬件加速卡,不仅对SSL非对称加解密算法(RSA、ECDH、ECDSA、DH、DSA等)具有加速,而且对数据的压缩与解压也具有加速效果;QAT加速卡提供zlib压缩算法、且zlib shim对其原生zlib与QAT之间做了适配,调用方式和zlib库方式基本一致,需在上层业务中开启zlib QAT模式、相对来说对上层业务改造较少.
    智能网卡
    INIC(Intelligent Network Interface Card)是网络研发事业部自研产品,以网络处理器为核心的高性能网络接入卡,对于网络报文数据的处理非常合适,针对Tengine的gzip卸载有如下两种方案:
    • 提供压缩API给host,把压缩数据返回host,由host封包发送;
    • host和网卡约定压缩flag,host发送未压缩报文,智能网卡收到后进行压缩,并且重新封包发送;
    FPGA卡
    FPGA(Field-Programmable Gate Array)现场可编程门阵列,需要对接入层使用的zlib算法使用硬件语言重新开发、进行电路烧写,且上层交互驱动也需要从零开发;
    方案对比
    智能网卡的方案1相比于QAT对zlib处理没有性能上的优势,智能网卡只是对zlib进行软件卸载、相对于QAT并不具有加速作用;其方案2需要把Tengine一部分业务逻辑抽取到网卡中做:如spdy、http2、chunked、ssl对称加密、响应body限速等逻辑,其成本及风险高,方案3的FPGA方式相对来说开发成本较高、且相关资源匮乏。
    综上所述最终采用QAT加速卡对接入层Tengine的Gzip进行卸载、加速。
    方案实施
    QAT驱动采用UIO(Userspace I/O)技术,其大部分处于用户态、只有少部分处理硬件中断应答等逻辑处于内核态,这样不仅方便用户调试,而且还解决了内核不支持浮点数运算的问题。当然QAT加速卡也顺应了Docker虚拟化的潮流,其采用SRIOV技术,可以在虚拟机之间高效共享PCIe(Peripheral Component Interconnect Express)设备,当前DH895XCC系列芯片最高可支持32个虚拟机共享QAT,从而达到充分利用硬件资源。其次QAT属于ASIC模式相比于FPGA具有更好的加速效果,主要原因是由于FPGA为了可重构,导致其逻辑查找表、触发器众多以及相同逻辑电路在布线上延时变大。
    接入层Tengine目前采用的是下图左边的实线加速链路,其中Zlib Shim、QAT User Space Api、QAT Driver作为Tengine Gzip与底层硬件QAT的通信适配层,此方式对上层业务入侵较小、其软件架构如下图所示:

    虽然该方案看起来比较简单,但是真正线上实施的时候还是遇到了非常多的问题(功能、性能方面),譬如:
    架构不合理
    • 使用的第一版驱动Intel-Qat2.6.0-60,当QPS为1k左右时CPU很快打满(注:正常情况下QPS为1k时,CPU消耗6%左右),且CPU消耗中90%以上都是消耗在内核态,如下图所示:
    使用strace进行相关系统热点函数统计发现,其CPU主要消耗在ioctl系统函数上,如下所示:
    通过perf查看ioctl主要是执行内存分配命令,由于Zlib Shim需要开辟连续的物理内存、所以出现频繁调用 compact_zone进行内碎片整理,其调用热的高达88.096%,如下图所示(注:热度表示该函数该函数自身的热度、调出: 表示被调用函数的热度总和、总体: 热度 + 调出):
    同Intel研发联调讨论后发现是由于当前Intel QAT的Zlib Shim的模型不合理所导致,通过推动其改造采用OOT的内存管理模块USDM(内部维护一个HugePage内存池)方案解决。
    • 使用上述问题解决后的驱动intel-qatOOT31092,测试后发现CPU节省效果不佳(用户态CPU减少、但是增加了内核态的CPU),经分析、发现使用QAT加速后,部分系统函数CPU占比变高,如 open、ioctl、futex,如下图所示(注:左边的是使用QAT后各系统热点函数),使用QAT后open、ioctl、futex执行时间占比高达8.95(注:3.91 + 2.68 + 2.36),而未使用版本对应占比时间才0.44(注:0.24 + 0.14 + 0.06);
    分析其Tengine的worker进程堆栈信息发现open、ioctl都是成对出现(即一次http请求出现4次该系统调用),该现象反馈给Intel的研发同学后得知是由于新驱动的Zlib Shim导致,通过优化改造后open、ioctl调用频率明显减少。但是其futex系统调用频度却没有减少,还是导致内核态的CPU占比较高,通过strace跟踪发现一个http压缩请求后会多次调用futex、如下图所示,同Intel研发同学了解到Zlib Shim采用多线程方式,其futex操作来自zlib shim等待QAT压缩或解压缩数据返回的逻辑。
    由于Tengine是多进程单线程、采用epoll异步IO事件模式,联调Intel的研发同学对Zlib Shim进行改造(去线程),最终futex系统调用也明显减少。
    通过分析并推动Intel对QAT进行多次架构上的改造,才使得QAT的加速特性更好的发挥。


    您需要登录后才可以回帖 登录 | 快速注册

    本版积分规则

    品牌广播台 更多>>
    便民工具
    返回顶部快速回复返回列表联系客服手机访问
    关于我们 | 联系我们 | 广告服务 | 网站导航 | 诚聘英才 | 友情链接 | 免责申明 |  帮助中心 | 手机访问 | 排行榜 | 小黑屋 | 设首页 | 加收藏
    © 2011-2017 上海论坛 版权所有 沪ICP备11017971号-7    在线客服 举报 郑重声明:本站只提供网上自由交流讨论,所有个人言论并不代表本站立场
    快速回复 返回顶部 返回列表