導(dǎo)讀：通用處理器（CPU）的摩爾定律已入暮年页响，而機(jī)器學(xué)習(xí)和Web服務(wù)的規(guī)模卻在指數(shù)級(jí)增長(zhǎng)闺魏。如何用硬件加速來(lái)提升性能非洲、降低成本阱驾？下面我們一起來(lái)看看就谜。
?一、背景介紹
通用處理器（CPU）的摩爾定律已入暮年里覆，而機(jī)器學(xué)習(xí)和Web服務(wù)的規(guī)模卻在指數(shù)級(jí)增長(zhǎng)。伴隨著當(dāng)今硬件技術(shù)的成熟發(fā)展缆瓣，普通CPU無(wú)論是在計(jì)算能力喧枷，還是資源成本上相對(duì)于一些專(zhuān)用硬件已經(jīng)沒(méi)有絕對(duì)優(yōu)勢(shì)，這也促使硬件加速技術(shù)得到各大公司的青睞弓坞，譬如三大互聯(lián)網(wǎng)巨頭百度隧甚、阿里、騰訊內(nèi)部的接入層采用類(lèi)似KeyLess方案來(lái)加速HTTPS的卸載渡冻，不僅提高了用戶(hù)體驗(yàn)戚扳，還節(jié)省了機(jī)器成本。根據(jù)當(dāng)前調(diào)研結(jié)果發(fā)現(xiàn)：目前業(yè)內(nèi)各大公司接入層針對(duì)于Gzip采用硬件加速還是一片空白族吻，阿里接入層首次結(jié)合硬件加速技術(shù)卸載Gzip不僅帶來(lái)了性能提升帽借，而且對(duì)業(yè)界在此領(lǐng)域的發(fā)展也有重大影響意義。?
接入層Tengine當(dāng)前性能瓶頸是CPU超歌，譬如Gzip模塊在Tengine中CPU占比高達(dá)15%-20%左右砍艾，相比于其它模塊CPU消耗高、占比呈增長(zhǎng)趨勢(shì)（后端應(yīng)用壓縮邏輯后續(xù)統(tǒng)一前置接入層）巍举、且集中脆荷，所以Gzip模塊使用硬件卸載對(duì)于性能提升、成本優(yōu)化是不可或缺懊悯。
二蜓谋、分析與調(diào)研
分析前先簡(jiǎn)單介紹下什么是硬件加速： 硬件加速（HardwareAcceleration）就是利用硬件模塊來(lái)替代軟件算法以充分利用硬件所固有的快速特性（硬件加速通常比軟件算法的效率要高），從而達(dá)到性能提升炭分、成本優(yōu)化目的桃焕，當(dāng)前主要是如下兩大加速方式：
◆ FPGA 現(xiàn)場(chǎng)可編程門(mén)陣列，可針對(duì)某個(gè)具體的軟件算法進(jìn)行定制化編程欠窒，譬如業(yè)內(nèi)的智能網(wǎng)卡覆旭；
◆?ASIC 專(zhuān)用集成電路，它是面向?qū)ｉT(mén)用途的電路岖妄、專(zhuān)門(mén)為一個(gè)用戶(hù)設(shè)計(jì)和制造的型将，譬如Intel的QAT卡僅支持特定加減密、壓縮算法荐虐；
FPGA與ASIC的對(duì)比如下表格所示：
?2.1七兜、接入層Tengine CPU消耗分析
主站接入層承載集團(tuán)90%以上的入口流量，看似只是作為一個(gè)七層流量轉(zhuǎn)發(fā)網(wǎng)關(guān)福扬，但是卻做了非常之多的事情腕铸，譬如https卸載及加速惜犀、單元化、智能流量轉(zhuǎn)發(fā)策略狠裹、灰度分流虽界、限流、安全防攻擊涛菠、流量鏡像莉御、鏈路追蹤、頁(yè)面打點(diǎn)等等俗冻，這一系列功能的背后是Tengine眾多模塊的支持礁叔。由于功能點(diǎn)比較多，所以這就導(dǎo)致Tengine的CPU消耗比較分散迄薄，其主流程處理如下圖所示：
?各模塊CPU消耗占比Top 5如下表格所示：
?就當(dāng)前接入層流量模型分析來(lái)看琅关，Gzip單個(gè)模塊CPU消耗占比達(dá)到15%-20%左右（注：主要是壓縮消耗）且占比呈上升趨勢(shì)，所以對(duì)Gzip使用硬件卸載迫在眉睫讥蔽。
2.2涣易、加速方案調(diào)研
2.2.1、Intel QAT卡
QAT(Quick Assist Technology)是Intel公司推出的一種專(zhuān)用硬件加速卡勤篮，不僅對(duì)SSL非對(duì)稱(chēng)加解密算法（RSA都毒、ECDH、ECDSA碰缔、DH账劲、DSA等）具有加速，而且對(duì)數(shù)據(jù)的壓縮與解壓也具有加速效果金抡；
QAT加速卡提供zlib壓縮算法瀑焦、且zlib shim對(duì)其原生zlib與QAT之間做了適配，調(diào)用方式和zlib庫(kù)方式基本一致梗肝，需在上層業(yè)務(wù)中開(kāi)啟zlib QAT模式榛瓮、相對(duì)來(lái)說(shuō)對(duì)上層業(yè)務(wù)改造較少。
2.2.2巫击、智能網(wǎng)卡
INIC（Intelligent Network Interface Card）是網(wǎng)絡(luò)研發(fā)事業(yè)部自研產(chǎn)品禀晓，以網(wǎng)絡(luò)處理器為核心的高性能網(wǎng)絡(luò)接入卡，對(duì)于網(wǎng)絡(luò)報(bào)文數(shù)據(jù)的處理非常合適坝锰，針對(duì)Tengine的gzip卸載有如下兩種方案：
◆?a. 提供壓縮API給host粹懒，把壓縮數(shù)據(jù)返回host，由host封包發(fā)送顷级；
◆?b. host和網(wǎng)卡約定壓縮flag凫乖，host發(fā)送未壓縮報(bào)文，智能網(wǎng)卡收到后進(jìn)行壓縮，并且重新封包發(fā)送帽芽；
2.2.3删掀、FPGA卡
FPGA（Field-Programmable Gate Array）現(xiàn)場(chǎng)可編程門(mén)陣列，需要對(duì)接入層使用的zlib算法使用硬件語(yǔ)言重新開(kāi)發(fā)导街、進(jìn)行電路燒寫(xiě)披泪，且上層交互驅(qū)動(dòng)也需要從零開(kāi)發(fā)；
方案對(duì)比
智能網(wǎng)卡的方案1相比于QAT對(duì)zlib處理沒(méi)有性能上的優(yōu)勢(shì)搬瑰，智能網(wǎng)卡只是對(duì)zlib進(jìn)行軟件卸載付呕、相對(duì)于QAT并不具有加速作用；其方案2需要把Tengine一部分業(yè)務(wù)邏輯抽取到網(wǎng)卡中做：如spdy跌捆、http2、chunked象颖、ssl對(duì)稱(chēng)加密佩厚、響應(yīng)body限速等邏輯，其成本及風(fēng)險(xiǎn)高说订，方案3的FPGA方式相對(duì)來(lái)說(shuō)開(kāi)發(fā)成本較高抄瓦、且相關(guān)資源匱乏。
綜上所述最終采用QAT加速卡對(duì)接入層Tengine的Gzip進(jìn)行卸載陶冷、加速钙姊。
三、方案實(shí)施
QAT驅(qū)動(dòng)采用UIO（UserspaceI/O）技術(shù)埂伦，其大部分處于用戶(hù)態(tài)煞额、只有少部分處理硬件中斷應(yīng)答等邏輯處于內(nèi)核態(tài)，這樣不僅方便用戶(hù)調(diào)試沾谜，而且還解決了內(nèi)核不支持浮點(diǎn)數(shù)運(yùn)算的問(wèn)題膊毁。當(dāng)然QAT加速卡也順應(yīng)了Docker虛擬化的潮流，其采用SRIOV技術(shù)基跑，可以在虛擬機(jī)之間高效共享PCIe（Peripheral Component Interconnect Express）設(shè)備婚温，當(dāng)前DH895XCC系列芯片最高可支持32個(gè)虛擬機(jī)共享QAT，從而達(dá)到充分利用硬件資源媳否。其次QAT屬于ASIC模式相比于FPGA具有更好的加速效果栅螟，主要原因是由于FPGA為了可重構(gòu)，導(dǎo)致其邏輯查找表篱竭、觸發(fā)器眾多以及相同邏輯電路在布線(xiàn)上延時(shí)變大力图。
接入層Tengine目前采用的是下圖左邊的實(shí)線(xiàn)加速鏈路，其中Zlib Shim室抽、QAT User Space Api搪哪、QAT Driver作為T(mén)engine Gzip與底層硬件QAT的通信適配層，此方式對(duì)上層業(yè)務(wù)入侵較小、其軟件架構(gòu)如下圖所示：
?雖然該方案看起來(lái)比較簡(jiǎn)單晓折，但是真正線(xiàn)上實(shí)施的時(shí)候還是遇到了非常多的問(wèn)題（功能惑朦、性能方面），譬如：
3.1漓概、架構(gòu)不合理
◆?a. 使用的第一版驅(qū)動(dòng)Intel-Qat2.6.0-60漾月，當(dāng)QPS為1k左右時(shí)CPU很快打滿(mǎn)（注：正常情況下QPS為1k時(shí)，CPU消耗6%左右）胃珍，且CPU消耗中90%以上都是消耗在內(nèi)核態(tài)梁肿，如下圖所示：
?使用strace進(jìn)行相關(guān)系統(tǒng)熱點(diǎn)函數(shù)統(tǒng)計(jì)發(fā)現(xiàn)，其CPU主要消耗在ioctl系統(tǒng)函數(shù)上觅彰，如下所示：
?通過(guò)perf查看ioctl主要是執(zhí)行內(nèi)存分配命令吩蔑，由于Zlib Shim需要開(kāi)辟連續(xù)的物理內(nèi)存、所以出現(xiàn)頻繁調(diào)用 compact_zone進(jìn)行內(nèi)碎片整理填抬，其調(diào)用熱的高達(dá)88.096%烛芬，如下圖所示（注：熱度表示該函數(shù)該函數(shù)自身的熱度、調(diào)出： 表示被調(diào)用函數(shù)的熱度總和飒责、總體： 熱度 + 調(diào)出）：
?同Intel研發(fā)聯(lián)調(diào)討論后發(fā)現(xiàn)是由于當(dāng)前Intel QAT的Zlib Shim的模型不合理所導(dǎo)致赘娄，通過(guò)推動(dòng)其改造采用OOT的內(nèi)存管理模塊USDM（內(nèi)部維護(hù)一個(gè)HugePage內(nèi)存池）方案解決。
◆?b. 使用上述問(wèn)題解決后的驅(qū)動(dòng)intel-qatOOT31092宏蛉，測(cè)試后發(fā)現(xiàn)CPU節(jié)省效果不佳（用戶(hù)態(tài)CPU減少遣臼、但是增加了內(nèi)核態(tài)的CPU），經(jīng)分析拾并、發(fā)現(xiàn)使用QAT加速后揍堰，部分系統(tǒng)函數(shù)CPU占比變高，如 open辟灰、ioctl个榕、futex，如下圖所示（注：左邊的是使用QAT后各系統(tǒng)熱點(diǎn)函數(shù)）芥喇，使用QAT后open西采、ioctl、futex執(zhí)行時(shí)間占比高達(dá)8.95（注：3.91 + 2.68 + 2.36）继控，而未使用版本對(duì)應(yīng)占比時(shí)間才0.44（注：0.24 + 0.14 + 0.06）械馆；
?分析其Tengine的worker進(jìn)程堆棧信息發(fā)現(xiàn)open、ioctl都是成對(duì)出現(xiàn)（即一次http請(qǐng)求出現(xiàn)4次該系統(tǒng)調(diào)用）武通，該現(xiàn)象反饋給Intel的研發(fā)同學(xué)后得知是由于新驅(qū)動(dòng)的Zlib Shim導(dǎo)致霹崎，通過(guò)優(yōu)化改造后open、ioctl調(diào)用頻率明顯減少冶忱。但是其futex系統(tǒng)調(diào)用頻度卻沒(méi)有減少尾菇，還是導(dǎo)致內(nèi)核態(tài)的CPU占比較高，通過(guò)strace跟蹤發(fā)現(xiàn)一個(gè)http壓縮請(qǐng)求后會(huì)多次調(diào)用futex、如下圖所示派诬，同Intel研發(fā)同學(xué)了解到Zlib Shim采用多線(xiàn)程方式劳淆，其futex操作來(lái)自zlib shim等待QAT壓縮或解壓縮數(shù)據(jù)返回的邏輯。
?由于Tengine是多進(jìn)程單線(xiàn)程默赂、采用epoll異步IO事件模式沛鸵，聯(lián)調(diào)Intel的研發(fā)同學(xué)對(duì)Zlib Shim進(jìn)行改造（去線(xiàn)程），最終futex系統(tǒng)調(diào)用也明顯減少缆八。
通過(guò)分析并推動(dòng)Intel對(duì)QAT進(jìn)行多次架構(gòu)上的改造曲掰，才使得QAT的加速特性更好的發(fā)揮。
3.2奈辰、功能不完善
◆?a. 使用QAT后執(zhí)行reload栏妖，可能導(dǎo)致請(qǐng)求響應(yīng)異常，如下所示：
?由于每個(gè)worker進(jìn)程都需要分配一個(gè)QAT Instance用于數(shù)據(jù)解壓縮奖恰，Tengine在reload的瞬間worker進(jìn)程數(shù)可能會(huì)翻倍底哥、而QAT Instance初始版本只有64個(gè)、所以新啟動(dòng)的worker進(jìn)程可能分配不到Instance房官、導(dǎo)致請(qǐng)求失敗。
針對(duì)此問(wèn)題Intel提供的新版本QAT续滋，其Instance數(shù)量從64提高到256個(gè)避免此問(wèn)題的發(fā)生翰守，同時(shí)我們提出容災(zāi)保護(hù)方案：當(dāng)Instance無(wú)法分配了需要自動(dòng)降級(jí)為軟件壓縮，提高其可用性疲酌。
◆?b. Zlib Shim huge page內(nèi)存泄漏蜡峰，導(dǎo)致QAT驅(qū)動(dòng)core dump：
Tengine使用內(nèi)存池模式進(jìn)行內(nèi)存的管理，即調(diào)用(In)DeflateInit分配的空間無(wú)需調(diào)用(In)DeflateEnd處理朗恳、在請(qǐng)求結(jié)束的時(shí)候會(huì)調(diào)用請(qǐng)求r相關(guān)的釋放操作湿颅，進(jìn)行內(nèi)存的歸還，但是由于Zlib Shim使用的huge page必須調(diào)用(In)DeflateEnd才釋放給USDM粥诫，通過(guò)改造Tengine Gzip相關(guān)代碼后油航，該問(wèn)題得以解決，而QAT驅(qū)動(dòng)的core dump也是由于hugepage的泄漏導(dǎo)致無(wú)法成功分配導(dǎo)致怀浆。
◆?c. Zlib Shim狀態(tài)機(jī)不完善導(dǎo)致特定場(chǎng)景下的壓縮谊囚、解壓縮請(qǐng)求異常，等眾多問(wèn)題就不一一介紹执赡。
一路走來(lái)镰踏，通過(guò)無(wú)數(shù)次的性能優(yōu)化、功能測(cè)試沙合，多次同Intel研發(fā)同學(xué)一起探討之后奠伪，才使得QAT在功能、性能、架構(gòu)方面等眾多問(wèn)題得以快速解決绊率，下面就準(zhǔn)備上線(xiàn)前期準(zhǔn)備工作谨敛。
3.3、運(yùn)維梳理
部署發(fā)布
采用單rpm軟件包即舌、雙二進(jìn)制模式佣盒，從而降低軟件版與硬件加速版之間的耦合度，自動(dòng)識(shí)別部署機(jī)器是否開(kāi)啟QAT顽聂，并選擇正確的二進(jìn)制執(zhí)行肥惭；
容災(zāi)保護(hù)
運(yùn)行過(guò)程中由于某種資源的缺乏導(dǎo)致硬件加速版本Gzip執(zhí)行失敗，將會(huì)自動(dòng)切換為軟件版本紊搪、待資源可用時(shí)自動(dòng)切換到硬件加速版本蜜葱；
可維護(hù)與監(jiān)控
雖然上線(xiàn)前做過(guò)一系列壓測(cè)、穩(wěn)定性并未出現(xiàn)異常耀石，但對(duì)硬件加速的相關(guān)資源指標(biāo)進(jìn)行實(shí)時(shí)監(jiān)控還是必不可少牵囤；
四、加速效果
測(cè)試機(jī)器
cpu型號(hào)：Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz? 32核??? 內(nèi)核：2.6.32 Zlib版本：zlib-1.2.8?? QAT驅(qū)動(dòng)版本：intel-qatOOT40052 ?
數(shù)據(jù)對(duì)比
同等條件下滞伟，開(kāi)啟QAT加速后CPU平均值為41%左右揭鳞，未開(kāi)啟QAT加速的CPU平均值為48%左右，如下圖所示：
?相同條件下梆奈，開(kāi)啟QAT加速后系統(tǒng)load平均值為12.09野崇，關(guān)閉QAT加速時(shí)系統(tǒng)load平均值為14.22，如下圖所示：
?相同條件下亩钟，開(kāi)啟與關(guān)閉QAT加速后乓梨，響應(yīng)RT波動(dòng)不相上下，如下所示：
?同等條件下清酥，各模塊熱點(diǎn)函數(shù)圖對(duì)比如下所示扶镀，其中紅色圈中的是Gzip相關(guān)函數(shù)
（注：左側(cè)是開(kāi)啟QAT加速）：
?同比條件下Tengine Gzip使用QAT加速卡后，CPU消耗從48%下降到41%焰轻，系統(tǒng)負(fù)載load下降2個(gè)臭觉，且根據(jù)模塊熱點(diǎn)函數(shù)圖對(duì)比發(fā)現(xiàn)Gzip基本上已經(jīng)完全卸載。
?結(jié)論
綜上數(shù)據(jù)對(duì)比辱志，當(dāng)qps為10k左右時(shí)Tengine Gzip使用QAT加速后CPU節(jié)省15%左右胧谈，且Gzip基本上完全卸載、隨著其占比變高荸频，優(yōu)化效果將越好菱肖。
五、總結(jié)
?
