在業(yè)務(wù)的性能調(diào)優(yōu)中，我們往往會遇到下面三個(gè)方面的問題：

1）操作系統(tǒng)的軟硬件配置過于繁雜。

無論是應(yīng)用內(nèi)核參數(shù)、系統(tǒng)服務(wù)還是應(yīng)用配置，都有成百上千的參數(shù)，而且參數(shù)之間相互，在調(diào)優(yōu)的時(shí)候往往存在蹺蹺板現(xiàn)象，如何管理如此大量的領(lǐng)域知識，是非常困難的事情。

2）人力、時(shí)間成本高。

做一次有效的全棧調(diào)優(yōu)，往往需要把多個(gè)領(lǐng)域的專家集中起來進(jìn)行一次1-3個(gè)月的集中攻關(guān)，在人力和時(shí)間成本上是非常大的代價(jià)。

3）專家知識難以固化復(fù)用。

即使是我們在一個(gè)場景上把所有專家集中起來做了一次非常好的攻關(guān)，專家知識還是非常難以固化下來并在下個(gè)應(yīng)用擴(kuò)展使用起來，到了下一次調(diào)優(yōu)場景，還是幾乎要重頭再來。

針對上述問題我們該如何求解呢？

如果專家知識非常難以固化，那我們?yōu)槭裁床唤ㄒ粋€(gè)專家知識庫平臺來把專家知識固化起來呢？

如果我們的配置關(guān)系非常復(fù)雜，投入時(shí)間和人力非常高，那我們?yōu)槭裁床话?a href="http://www.nxhydt.com/tags/ai/" target="_blank">AI算法引入進(jìn)來，讓人工智能幫我們做一些事情。

??

在容量評估測試中，我們也會遇到類似的問題：Benchmark的參數(shù)眾多，哪些參數(shù)是需要使用的，哪些其實(shí)無關(guān)緊要？需要使用的參數(shù)，如何設(shè)置它的值才能保證給出的壓力是足夠的，從而不會因?yàn)閴毫Σ蛔愣鵁o法驗(yàn)證到物理機(jī)/系統(tǒng)真實(shí)的容量呢？

I可行的解決途徑——KeenTune的緣起

從上個(gè)部分中，我們其實(shí)可以看出求解的方式，一個(gè)是需要專家知識的固化平臺，一個(gè)是可以考慮引入AI算法來解決人工無法有效探索參數(shù)取值空間的問題。這也就是KeenTune的起源，其主要完成兩大部分的功能，一方面將人工的經(jīng)驗(yàn)固化下來，形成能夠在業(yè)務(wù)上一鍵調(diào)優(yōu)的專家知識庫——也就是靜態(tài)調(diào)優(yōu)；另一方面，在有了需要調(diào)優(yōu)的參數(shù)及其取值空間的概要知識的情況下，可以使用AI算法來進(jìn)行最優(yōu)取值搜索。

這是KeenTune產(chǎn)品開始研發(fā)時(shí)最樸素的想法，后面也因?yàn)闃I(yè)務(wù)的實(shí)際需要，引入了參數(shù)可解釋性方向的算法，來識別出來哪些參數(shù)對結(jié)果真實(shí)有影響，其最優(yōu)取值范圍是什么，從而指導(dǎo)進(jìn)行人工解釋和進(jìn)一步研究；同時(shí)，也引入了高保真方向的算法來規(guī)避Benchmark/業(yè)務(wù)環(huán)境的波動(dòng)對調(diào)優(yōu)效果的準(zhǔn)確性帶來的影響；另外，也針對“在不增加時(shí)延的情況下，提升吞吐量”這樣的帶控制條件的實(shí)際調(diào)優(yōu)需求，引入了多目標(biāo)調(diào)優(yōu)方向的算法。

請注意，KeenTune提供的動(dòng)靜態(tài)協(xié)同調(diào)優(yōu)的能力，可以協(xié)助實(shí)際業(yè)務(wù)解決如下問題：

1）POC小集群調(diào)優(yōu)到線上大規(guī)模集群調(diào)優(yōu)，比如：POC小集群動(dòng)態(tài)調(diào)優(yōu)完后，調(diào)優(yōu)經(jīng)驗(yàn)固化成靜態(tài)調(diào)優(yōu)，直接大規(guī)模部署到線上；

2）相似場景的精細(xì)化調(diào)優(yōu)，比如：調(diào)優(yōu)過mysql后，使用mysql的固化出的靜態(tài)專家知識庫，轉(zhuǎn)化成動(dòng)態(tài)進(jìn)行精細(xì)化調(diào)優(yōu)。

在算法創(chuàng)新的同時(shí)，基于阿里業(yè)務(wù)自身的特點(diǎn)，KeenTune采用了高度模塊化的分布式部署的方式，在業(yè)務(wù)端只需要部署輕量的agent（keentune-target），管控調(diào)度模塊keentuned，算法模塊keentune-brain，Benchmark管控模塊keentune-bench，前端管控與算法可視化模塊keentune-ui都是可以部署在網(wǎng)絡(luò)可連通的其他環(huán)境上，因此，對業(yè)務(wù)的適配度非常高。

一、創(chuàng)新點(diǎn)

KeenTune項(xiàng)目目前已經(jīng)提交13篇專利，其中9篇已提交專利；另外，還有3篇正在提交流程中。A類論文發(fā)表1篇（FSE2022：KeenTune: Inteligent Parameter Interpretability and Tuning Tool for Linux System），1篇在投A類論文。

本章節(jié)的各小節(jié)中，后續(xù)也會簡單介紹一下KeenTune的創(chuàng)新點(diǎn)。

I多領(lǐng)域算法的集成

KeenTune主要使用的算法為Hyper Parameter Tuning方向，目標(biāo)是在參數(shù)空間上尋找最優(yōu)組合。不過，在實(shí)際應(yīng)用落地中，發(fā)現(xiàn)在實(shí)際應(yīng)用中會存在很多問題：

1）在高維空間上，無論是傳統(tǒng)的Bayes，還是更新的HORD、EPTE等算法，都無法達(dá)到工程需求的快速收斂（比如：100個(gè)連續(xù)/分散取值的參數(shù)，在100輪達(dá)成收斂目標(biāo)），而一般Benchmark的執(zhí)行時(shí)間都會在幾分鐘甚至幾小時(shí)，每一輪執(zhí)行代價(jià)都非常大，因此，降低輪次成為首要問題。

2）非單一目標(biāo)調(diào)優(yōu)，在實(shí)際中，往往是“不增加時(shí)延的情況下提升吞吐”、“不僅avg_latency降低，還要求99_latency、95_latency都降低” 3）無論是Benchmark還是業(yè)務(wù)環(huán)境，都存在抖動(dòng)的問題，如何識別出環(huán)境抖動(dòng)并且盡量消除，是個(gè)問題。

為應(yīng)對這些問題，KeenTune集成了多個(gè)領(lǐng)域的算法來使參數(shù)調(diào)優(yōu)在實(shí)際工程中能夠產(chǎn)生效果：

敏感參數(shù)可解釋性方向算法：從眾多的參數(shù)中識別出真正對結(jié)果有影響的TOP參數(shù)，并且能夠給出其最優(yōu)取值的范圍，給出參考。一方面，可以成為參數(shù)調(diào)優(yōu)算法的輸入，大大降低參數(shù)空間，從而實(shí)現(xiàn)快速找到優(yōu)化點(diǎn)的目標(biāo)。另一方面，也可以為人工提煉專家靜態(tài)知識庫并進(jìn)行領(lǐng)域分析提供依據(jù)。

多目標(biāo)調(diào)優(yōu)算法：KeenTune自研的帶有可控制條件的多目標(biāo)調(diào)優(yōu)，有效地解決了工程中遇到的各種多個(gè)評價(jià)指標(biāo)同時(shí)調(diào)優(yōu)，甚至是帶有強(qiáng)制限制條件的調(diào)優(yōu)問題。

高保真算法：能夠通過評估環(huán)境的波動(dòng)情況，調(diào)整每輪運(yùn)行的次數(shù)，從而保證調(diào)優(yōu)效果。另外，結(jié)合early stop機(jī)制，能夠智能化控制實(shí)際的運(yùn)行效率，從而大大提升對于每次調(diào)優(yōu)的收斂效率。

I自研參數(shù)調(diào)優(yōu)算法BGCS

為了實(shí)現(xiàn)高效可擴(kuò)展的參數(shù)調(diào)優(yōu)算法，BGCS參考了HORD框架進(jìn)行了改進(jìn)，使用CNN/MLP模型取代RBF模型作為代理模型，以提高代理模型預(yù)測準(zhǔn)確性。

在HORD算法的DYCORS過程中，通過兩個(gè)變量φ和δ來控制變異的過程，前者控制的是給坐標(biāo)的某個(gè)維度進(jìn)行變異的概率，后者決定了增加變異的幅度。在調(diào)優(yōu)過程中，φ隨著調(diào)優(yōu)的進(jìn)行遞減，而δ根據(jù)每一輪是否發(fā)現(xiàn)了新的最優(yōu)參數(shù)進(jìn)行動(dòng)態(tài)調(diào)整。

雖然有兩個(gè)變量干預(yù)參數(shù)的變異，但HORD算法的參數(shù)變異過程整體來說是隨機(jī)的，在這個(gè)過程中會產(chǎn)生大量無意義的參數(shù)配置。我們針對這個(gè)過程加入性能梯度對參數(shù)編譯的過程進(jìn)行指導(dǎo)，避免盲目隨機(jī)地生成大量參數(shù)配置。同時(shí)使用梯度對參數(shù)維度進(jìn)行排序，優(yōu)先針對性能梯度較高的參數(shù)進(jìn)行變異，同時(shí)保持性能梯度低參數(shù)的取值，降低代理模型預(yù)測誤差的干擾。

I自研參數(shù)可解釋性算法XSen

為了達(dá)成算法能夠正確的找到真正對結(jié)果產(chǎn)生影響的參數(shù)，PIA將多種不同的敏感參數(shù)領(lǐng)域算法進(jìn)行融合，根據(jù)實(shí)際情況使用。下圖中列出了PIA的框架，主要是分為analyzer和aggregator。

Analyzer分為mutual information analyzer、linear analyzer、non-linear analyzer三種。Non-linear analyzer分為兩種：DNN模型、樹形模型，linear analyzer使用線性模型。在工程驗(yàn)證中，高維度non-linear analyzer的準(zhǔn)確度更高，但是運(yùn)行時(shí)間較久；linear analyzer運(yùn)行時(shí)間在1s內(nèi)，不過準(zhǔn)確度相對不高。mutual information analyzer捕捉線性和非線性信息，通過信息識別來識別敏感參數(shù)。

二、應(yīng)用實(shí)踐

IKeenTune在Linux全棧性能調(diào)優(yōu)中的實(shí)踐

KeenTune不僅在算法層面上實(shí)現(xiàn)了對kernel、environment configuration、runtime、compiler、application的多個(gè)層級的參數(shù)的動(dòng)態(tài)算法調(diào)優(yōu)，還積累了包括多層級的人工經(jīng)驗(yàn)。目前，在云場景、云原生場景、編譯器場景等多個(gè)合作項(xiàng)目中達(dá)成了調(diào)優(yōu)目標(biāo)，并且在社區(qū)中與統(tǒng)信、中興、intel等SIG伙伴進(jìn)行相關(guān)共建。

1. 專家一鍵式調(diào)優(yōu) –MySQL的競分打榜

項(xiàng)目背景：

某商業(yè)打榜

調(diào)優(yōu)目標(biāo)：

AnolisOS提供自研性能調(diào)優(yōu)工具能力，主流應(yīng)用（MySQL）調(diào)優(yōu)能力不低于友商

調(diào)優(yōu)效果：

MySQL的TPCC跑分在一鍵式專家調(diào)優(yōu)后，相比初始安裝性能提升10倍+

2. 敏感參數(shù)識別 –Nginx業(yè)務(wù)的參數(shù)可解釋性

項(xiàng)目背景：

調(diào)優(yōu)參數(shù)多導(dǎo)致參數(shù)空間巨大，進(jìn)而導(dǎo)致參數(shù)調(diào)優(yōu)算法收斂慢（100參數(shù)收斂需要2000輪以上）

調(diào)優(yōu)目標(biāo)：

116個(gè)聯(lián)合參數(shù)（內(nèi)核+ Nginx) 中對結(jié)果影響大的參數(shù)，目標(biāo)20個(gè)以內(nèi)

識別效果：

TOP10參數(shù)對Nginx吞吐與時(shí)延的影響已經(jīng)超過90%，降維后調(diào)優(yōu)效果和全量保持一致

3. 智能參數(shù)調(diào)優(yōu) – 云原生業(yè)務(wù)Ingress-Nginx的全棧調(diào)優(yōu)

項(xiàng)目背景：

調(diào)優(yōu)參數(shù)多導(dǎo)致參數(shù)空間巨大，進(jìn)而導(dǎo)致參數(shù)調(diào)優(yōu)算法收斂慢（100參數(shù)收斂需要500輪以上）

調(diào)優(yōu)目標(biāo)：

四個(gè)場景完整覆蓋：HTTP短鏈接，HTTP長鏈接，HTTPs短鏈接，HTTPs長鏈接

多領(lǐng)域參數(shù)協(xié)同調(diào)優(yōu)：Sysctl，Nginx

兩個(gè)指標(biāo)統(tǒng)一優(yōu)化：Throughput提升的同時(shí)Latency下降

調(diào)優(yōu)效果：

四個(gè)場景均達(dá)成了throughput提升的同時(shí)latency下降，有些場景最好效果達(dá)到40%+

達(dá)成內(nèi)核到應(yīng)用的全棧調(diào)優(yōu)，取得良好效果

同時(shí)，在其中，尤其是長連接的場景，對比了只進(jìn)行nginx.conf參數(shù)調(diào)優(yōu)，與內(nèi)核+Nginx的全量調(diào)優(yōu)的對比，可以非常明顯的看出，多層級的全棧調(diào)優(yōu)效果會比單一層級的調(diào)優(yōu)效果突出。

4. 智能參數(shù)調(diào)優(yōu) – 云業(yè)務(wù)gcc編譯參數(shù)調(diào)優(yōu)

項(xiàng)目背景：

gcc編譯參數(shù)對應(yīng)用性能影響較大，人工定義配置比較困難

調(diào)優(yōu)目標(biāo)：

對云業(yè)務(wù)上TOP3的應(yīng)用進(jìn)行編譯參數(shù)優(yōu)化

調(diào)優(yōu)效果：

TOP3應(yīng)用的主要指標(biāo)均達(dá)成調(diào)優(yōu)目標(biāo)（目標(biāo)1-3%）

IKeenTune在容量評估方向的實(shí)踐

容量評估一直一直以來的痛點(diǎn)，就是Benchmark工具，大家都知道是什么，怎么用，不過卻不一定能夠用對。現(xiàn)在集團(tuán)內(nèi)的使用方式基本上還是人工定義性能測試用例，用這個(gè)結(jié)果直接評估是否正確，這就對Benchmark使用人員有著非常高的要求，怎么創(chuàng)建模型，定義Benchmark的各個(gè)參數(shù)是很有講究的。

往往存在直接從網(wǎng)上找到使用的命令行方式，修改修改參數(shù)，跑出來個(gè)結(jié)果就開始做分析。可是這樣子就會有幾個(gè)問題：

1）不少Benchmark的參數(shù)都非常多，比如：sysbench，那么，哪些參數(shù)是我們需要關(guān)注并且使用的呢？

2）在不同規(guī)格的機(jī)器上，都使用相同一套參數(shù)的測試用例，是不是不合適？換個(gè)說法，是否能夠提供足夠的壓力用來提供容量評估？

3）Benchmark本身的資源消耗怎樣？會不會因?yàn)閰?shù)設(shè)置不當(dāng)，或者環(huán)境選用不當(dāng)，導(dǎo)致Benchmark自己占掉了所有資源而無法給出足夠壓力？這一點(diǎn)在wrk上非常明顯。

為了解決這些問題，KeenTune的參數(shù)調(diào)優(yōu)算法登場了，開始在看似不屬于自己的領(lǐng)域，進(jìn)行了一些還挺有效果的實(shí)踐。

1. 基礎(chǔ)Benchmark的壓力管控 – iperf3網(wǎng)絡(luò)帶寬測試

項(xiàng)目背景：

在與私有云團(tuán)隊(duì)進(jìn)行容量評估的需求分析時(shí)，發(fā)現(xiàn)使用人工用例進(jìn)行容量評估，往往存在因?yàn)锽enchmark壓力不足導(dǎo)致無法測出真實(shí)容量

壓控目標(biāo)：

通過動(dòng)態(tài)控壓，評測出硬件和云上環(huán)境的真實(shí)容量

壓控效果：

相比人工測試用例，評測出更真實(shí)的網(wǎng)絡(luò)容量，高出10%+

管控更多工具參數(shù)，并且能夠提供最佳效果取值范圍

說明：左邊的兩個(gè)圖分別是iperf3進(jìn)行接收端和發(fā)送端容量評估時(shí)，iperf3中參數(shù)真正對結(jié)果有效果的3個(gè)參數(shù)，右邊的兩列圖，分別給出來了接收端和發(fā)送端在當(dāng)前規(guī)格機(jī)器中這三個(gè)敏感參數(shù)的取值推薦。

2. 應(yīng)用的調(diào)優(yōu)、壓力雙控 – MySQL的調(diào)優(yōu)與變壓

項(xiàng)目背景：

進(jìn)行應(yīng)用的調(diào)優(yōu)時(shí)，需要解決兩部分問題:（1）Benchmark壓力不足；（2）應(yīng)用環(huán)境及自身調(diào)優(yōu)

壓控目標(biāo)：

同時(shí)管控MySQL與Benchmark的參數(shù)，保證壓力控制的狀況下進(jìn)行MySQL調(diào)優(yōu)

審核編輯：劉清