在業務的性能調優中，我們往往會遇到下面三個方面的問題：

1）操作系統的軟硬件配置過于繁雜。

無論是應用內核參數、系統服務還是應用配置，都有成百上千的參數，而且參數之間相互，在調優的時候往往存在蹺蹺板現象，如何管理如此大量的領域知識，是非常困難的事情。

2）人力、時間成本高。

做一次有效的全棧調優，往往需要把多個領域的專家集中起來進行一次1-3個月的集中攻關，在人力和時間成本上是非常大的代價。

3）專家知識難以固化復用。

即使是我們在一個場景上把所有專家集中起來做了一次非常好的攻關，專家知識還是非常難以固化下來并在下個應用擴展使用起來，到了下一次調優場景，還是幾乎要重頭再來。

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

如果專家知識非常難以固化，那我們為什么不建一個專家知識庫平臺來把專家知識固化起來呢？

如果我們的配置關系非常復雜，投入時間和人力非常高，那我們為什么不把AI算法引入進來，讓人工智能幫我們做一些事情。

??

在容量評估測試中，我們也會遇到類似的問題：Benchmark的參數眾多，哪些參數是需要使用的，哪些其實無關緊要？需要使用的參數，如何設置它的值才能保證給出的壓力是足夠的，從而不會因為壓力不足而無法驗證到物理機/系統真實的容量呢？

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

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

這是KeenTune產品開始研發時最樸素的想法，后面也因為業務的實際需要，引入了參數可解釋性方向的算法，來識別出來哪些參數對結果真實有影響，其最優取值范圍是什么，從而指導進行人工解釋和進一步研究；同時，也引入了高保真方向的算法來規避Benchmark/業務環境的波動對調優效果的準確性帶來的影響；另外，也針對“在不增加時延的情況下，提升吞吐量”這樣的帶控制條件的實際調優需求，引入了多目標調優方向的算法。

請注意，KeenTune提供的動靜態協同調優的能力，可以協助實際業務解決如下問題：

1）POC小集群調優到線上大規模集群調優，比如：POC小集群動態調優完后，調優經驗固化成靜態調優，直接大規模部署到線上；

2）相似場景的精細化調優，比如：調優過mysql后，使用mysql的固化出的靜態專家知識庫，轉化成動態進行精細化調優。

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

一、創新點

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

本章節的各小節中，后續也會簡單介紹一下KeenTune的創新點。

I多領域算法的集成

KeenTune主要使用的算法為Hyper Parameter Tuning方向，目標是在參數空間上尋找最優組合。不過，在實際應用落地中，發現在實際應用中會存在很多問題：

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

2）非單一目標調優，在實際中，往往是“不增加時延的情況下提升吞吐”、“不僅avg_latency降低，還要求99_latency、95_latency都降低” 3）無論是Benchmark還是業務環境，都存在抖動的問題，如何識別出環境抖動并且盡量消除，是個問題。

為應對這些問題，KeenTune集成了多個領域的算法來使參數調優在實際工程中能夠產生效果：

敏感參數可解釋性方向算法：從眾多的參數中識別出真正對結果有影響的TOP參數，并且能夠給出其最優取值的范圍，給出參考。一方面，可以成為參數調優算法的輸入，大大降低參數空間，從而實現快速找到優化點的目標。另一方面，也可以為人工提煉專家靜態知識庫并進行領域分析提供依據。

多目標調優算法：KeenTune自研的帶有可控制條件的多目標調優，有效地解決了工程中遇到的各種多個評價指標同時調優，甚至是帶有強制限制條件的調優問題。

高保真算法：能夠通過評估環境的波動情況，調整每輪運行的次數，從而保證調優效果。另外，結合early stop機制，能夠智能化控制實際的運行效率，從而大大提升對于每次調優的收斂效率。

I自研參數調優算法BGCS

為了實現高效可擴展的參數調優算法，BGCS參考了HORD框架進行了改進，使用CNN/MLP模型取代RBF模型作為代理模型，以提高代理模型預測準確性。

在HORD算法的DYCORS過程中，通過兩個變量φ和δ來控制變異的過程，前者控制的是給坐標的某個維度進行變異的概率，后者決定了增加變異的幅度。在調優過程中，φ隨著調優的進行遞減，而δ根據每一輪是否發現了新的最優參數進行動態調整。

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

I自研參數可解釋性算法XSen

為了達成算法能夠正確的找到真正對結果產生影響的參數，PIA將多種不同的敏感參數領域算法進行融合，根據實際情況使用。下圖中列出了PIA的框架，主要是分為analyzer和aggregator。

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

二、應用實踐

IKeenTune在Linux全棧性能調優中的實踐

KeenTune不僅在算法層面上實現了對kernel、environment configuration、runtime、compiler、application的多個層級的參數的動態算法調優，還積累了包括多層級的人工經驗。目前，在云場景、云原生場景、編譯器場景等多個合作項目中達成了調優目標，并且在社區中與統信、中興、intel等SIG伙伴進行相關共建。

1. 專家一鍵式調優 –MySQL的競分打榜

項目背景：

某商業打榜

調優目標：

AnolisOS提供自研性能調優工具能力，主流應用（MySQL）調優能力不低于友商

調優效果：

MySQL的TPCC跑分在一鍵式專家調優后，相比初始安裝性能提升10倍+

2. 敏感參數識別 –Nginx業務的參數可解釋性

項目背景：

調優參數多導致參數空間巨大，進而導致參數調優算法收斂慢（100參數收斂需要2000輪以上）

調優目標：

116個聯合參數（內核+ Nginx) 中對結果影響大的參數，目標20個以內

識別效果：

TOP10參數對Nginx吞吐與時延的影響已經超過90%，降維后調優效果和全量保持一致

3. 智能參數調優 – 云原生業務Ingress-Nginx的全棧調優

項目背景：

調優參數多導致參數空間巨大，進而導致參數調優算法收斂慢（100參數收斂需要500輪以上）

調優目標：

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

多領域參數協同調優：Sysctl，Nginx

兩個指標統一優化：Throughput提升的同時Latency下降

調優效果：

四個場景均達成了throughput提升的同時latency下降，有些場景最好效果達到40%+

達成內核到應用的全棧調優，取得良好效果

同時，在其中，尤其是長連接的場景，對比了只進行nginx.conf參數調優，與內核+Nginx的全量調優的對比，可以非常明顯的看出，多層級的全棧調優效果會比單一層級的調優效果突出。

4. 智能參數調優 – 云業務gcc編譯參數調優

項目背景：

gcc編譯參數對應用性能影響較大，人工定義配置比較困難

調優目標：

對云業務上TOP3的應用進行編譯參數優化

調優效果：

TOP3應用的主要指標均達成調優目標（目標1-3%）

IKeenTune在容量評估方向的實踐

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

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

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

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

3）Benchmark本身的資源消耗怎樣？會不會因為參數設置不當，或者環境選用不當，導致Benchmark自己占掉了所有資源而無法給出足夠壓力？這一點在wrk上非常明顯。

為了解決這些問題，KeenTune的參數調優算法登場了，開始在看似不屬于自己的領域，進行了一些還挺有效果的實踐。

1. 基礎Benchmark的壓力管控 – iperf3網絡帶寬測試

項目背景：

在與私有云團隊進行容量評估的需求分析時，發現使用人工用例進行容量評估，往往存在因為Benchmark壓力不足導致無法測出真實容量

壓控目標：

通過動態控壓，評測出硬件和云上環境的真實容量

壓控效果：

相比人工測試用例，評測出更真實的網絡容量，高出10%+

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

說明：左邊的兩個圖分別是iperf3進行接收端和發送端容量評估時，iperf3中參數真正對結果有效果的3個參數，右邊的兩列圖，分別給出來了接收端和發送端在當前規格機器中這三個敏感參數的取值推薦。

2. 應用的調優、壓力雙控 – MySQL的調優與變壓

項目背景：

進行應用的調優時，需要解決兩部分問題:（1）Benchmark壓力不足；（2）應用環境及自身調優

壓控目標：

同時管控MySQL與Benchmark的參數，保證壓力控制的狀況下進行MySQL調優

審核編輯：劉清