呂依蓉 孫 斌 喻之斌
1(中國科學(xué)院深圳先進(jìn)技術(shù)研究院 深圳 518055)
2(中國科學(xué)院大學(xué) 北京 100049)
3(首都師范大學(xué)信息工程學(xué)院 北京 100048)
隨著云計(jì)算的發(fā)展,數(shù)據(jù)中心作為計(jì)算和存儲(chǔ)的核心在運(yùn)維管理方面遇到了諸多問題和挑戰(zhàn)。為了分析、優(yōu)化程序以及有效地管理系統(tǒng)資源,程序員和系統(tǒng)運(yùn)維人員都需要精確獲取系統(tǒng)運(yùn)行時(shí)的底層信息。性能計(jì)數(shù)器是用于硬件事件計(jì)數(shù)的一類寄存器,它們可以在時(shí)鐘周期級(jí)別、低代價(jià)地監(jiān)測(cè)并記錄系統(tǒng)運(yùn)行中產(chǎn)生的各類硬件事件。這些性能事件隨著時(shí)間推移可以輕易地產(chǎn)生大量數(shù)據(jù)。 在云計(jì)算的環(huán)境下,數(shù)以千計(jì)的服務(wù)器和數(shù)以億計(jì)的負(fù)載應(yīng)用使硬件事件數(shù)據(jù)量更大,如谷歌的云平臺(tái)每天產(chǎn)生幾個(gè) GB甚至幾個(gè) TB 的中央處理器(Central Processing Unit,CPU)性能數(shù)據(jù),我們稱之為處理器性能大數(shù)據(jù)。這些性能事件實(shí)際上隱含著影響云計(jì)算負(fù)載性能的關(guān)鍵因素。因此,性能計(jì)數(shù)器和硬件性能事件被廣泛地應(yīng)用在任務(wù)調(diào)度[1,2]、負(fù)載特征刻畫[3-10]、編譯器優(yōu)化[11-13]和體系結(jié)構(gòu)優(yōu)化[14-17]等方面。與此同時(shí),一系列基于性能計(jì)數(shù)器的軟件工具也應(yīng)運(yùn)而生,如 perf_event[18]、PAPI[19]、VTune 和 Oprof i le[20]等。
在云計(jì)算時(shí)代,性能計(jì)數(shù)器變得更加重要。許多云服務(wù)提供商都渴望通過性能計(jì)數(shù)器來理解云服務(wù)的性能瓶頸。這是因?yàn)榧词股倭康男阅芴嵘?如1%)也能帶來巨大的經(jīng)濟(jì)效益(如數(shù)百萬美元)[3]。
然而,在云計(jì)算時(shí)代使用 CPU 性能計(jì)數(shù)器產(chǎn)生的數(shù)據(jù)面臨著一個(gè)新的挑戰(zhàn)——海量的、無規(guī)律的 CPU 性能數(shù)據(jù)難以理解。谷歌的工程師曾報(bào)告[3]他們每天通過 GWP 工具從谷歌的數(shù)據(jù)中心收集幾個(gè) GB 的 CPU 性能數(shù)據(jù)。如果將一個(gè)硬件事件視為一個(gè)維度,這些數(shù)據(jù)將是非常高維的數(shù)據(jù)。例如,因特爾的 Haswell 架構(gòu)規(guī)定了 229 個(gè)性能事件,則這款處理器的性能數(shù)據(jù)有229 維[21];因特爾的 IvyTown 架構(gòu)規(guī)定了 1 423 個(gè)性能事件,則 IvyTown 的性能數(shù)據(jù)有 1 423 維[22]。如果同等對(duì)待每個(gè)事件產(chǎn)生的數(shù)據(jù),則需要付出巨大的努力來處理、分析和利用 CPU 性能大數(shù)據(jù)。為了方便對(duì)性能數(shù)據(jù)進(jìn)行分析,需要通過以下 3 個(gè)方面:(1)量化性能事件對(duì)性能的重要性;(2)發(fā)現(xiàn)事件與性能的聯(lián)系;(3)理解事件之間的相互作用。然而,這 3 個(gè)方面還未曾在計(jì)算機(jī)系統(tǒng)結(jié)構(gòu)和云計(jì)算系統(tǒng)中進(jìn)行研究。
因此,本文提出一種云平臺(tái)上的 CPU 性能大數(shù)據(jù)挖掘方法,借助性能計(jì)數(shù)器性能監(jiān)測(cè)工具,對(duì)大量硬件事件進(jìn)行性能重要性排序,尋找事件模式,從而有效地度量和理解云平臺(tái)上的性能大數(shù)據(jù)。本文的主要貢獻(xiàn)如下:
(1)單計(jì)數(shù)器單事件(One Counter One Event,OCOE)方式下性能監(jiān)測(cè)數(shù)據(jù)的拼接與整合。由于性能監(jiān)測(cè)數(shù)據(jù)無法一次性測(cè)量,因此數(shù)據(jù)片段首先需要進(jìn)行融合。而多組測(cè)量數(shù)據(jù)之間可能出現(xiàn)事件集重疊的現(xiàn)象,造成了數(shù)據(jù)不對(duì)齊的問題。本文通過設(shè)計(jì)并實(shí)現(xiàn)了 CPU 性能數(shù)據(jù)融合的方法。
(2)性能事件對(duì)性能的重要性量化。用來采集硬件事件信息的性能計(jì)數(shù)器數(shù)量是有限的,而且用戶往往并不需要利用所有的硬件事件,即只需要少數(shù)重要的硬件事件便可以分析負(fù)載特征并進(jìn)行性能優(yōu)化。本文首先提出基于機(jī)器學(xué)習(xí)的硬件事件重要性量化方法,然后再用迭代排序不斷約簡(jiǎn)事件空間,最后提煉出一組重要的事件。
本文采用 8 個(gè) Apache Spark 程序進(jìn)行實(shí)驗(yàn),所建模型在測(cè)試集上的精度達(dá)到了 95%。另外,我們還用此方法精確刻畫了不同的 Spark 程序之間的個(gè)性與共性特征。
現(xiàn)代處理器一般集成了 4~8 個(gè)性能計(jì)數(shù)器[21,23]。其中,性能計(jì)數(shù)器是一類用在時(shí)鐘周期級(jí)別測(cè)量處理器性能事件的特殊寄存器。性能事件是指可由性能計(jì)數(shù)器測(cè)量的、處理器內(nèi)的硬件事件,如時(shí)鐘周期數(shù)、執(zhí)行的指令數(shù)以及各級(jí)高速緩存的命中次數(shù)等[24]。此類硬件事件種類豐富、功能齊全,不僅可以進(jìn)行實(shí)時(shí)監(jiān)測(cè),還可以精確到時(shí)鐘周期級(jí)別。有的事件還被細(xì)分成更細(xì)粒度的子事件,如高速緩存缺失事件可以被分為數(shù)據(jù)讀取階段的缺失、數(shù)據(jù)寫入階段的缺失、取指令階段的缺失及指令預(yù)取階段的缺失等[25]。系統(tǒng)所支持的事件因處理器而異,不同的供應(yīng)商會(huì)提供不同的硬件事件集;甚至同一處理供應(yīng)商為不同架構(gòu)的處理器提供不同數(shù)量的硬件事件。一般來說,處理器能支持?jǐn)?shù)百個(gè)硬件事件。例如,因特爾為 Haswell 架構(gòu)的處理器提供了 229個(gè)硬件事件[21],而為 IvyTown 架構(gòu)的處理器提供了 1 423 個(gè)硬件事件[22]。
通過實(shí)時(shí)監(jiān)測(cè)硬件事件,可以分析程序運(yùn)行時(shí)的行為,從而獲得負(fù)載的性能、功耗和能效等特征。而這些特征可以作為資源調(diào)整、任務(wù)調(diào)度策略的依據(jù),最終達(dá)到優(yōu)化能效的目的。
然而,性能計(jì)數(shù)器在使用過程中面臨著一個(gè)重大挑戰(zhàn):可用的計(jì)數(shù)器數(shù)目相對(duì)保持固定,但需要監(jiān)測(cè)的性能事件的數(shù)目卻愈發(fā)增多,遠(yuǎn)遠(yuǎn)大于可用的計(jì)數(shù)器數(shù)目。
少量的性能計(jì)數(shù)器和大量的待監(jiān)測(cè)性能事件使監(jiān)測(cè)效率和監(jiān)測(cè)結(jié)果準(zhǔn)確度之間出現(xiàn)了矛盾。為了提高效率,很多研究采用多路復(fù)用(Multiplexing,MLPX)的監(jiān)測(cè)方式[26-28]。采用MLPX 方式時(shí),只需要完整地運(yùn)行負(fù)載程序一次,期間每個(gè)性能計(jì)數(shù)器通過輪詢的方式監(jiān)測(cè)多個(gè)硬件事件。最后,每個(gè)硬件事件根據(jù)被記錄到的片段推算出在負(fù)載整個(gè)運(yùn)行期間的表現(xiàn)。由于每個(gè)硬件事件只在負(fù)載程序運(yùn)行過程中的一部分時(shí)間內(nèi)被監(jiān)測(cè)到,導(dǎo)致其性能表現(xiàn)在最終的結(jié)果數(shù)據(jù)中并未被完全體現(xiàn)出來,許多關(guān)鍵信息也許會(huì)在輪詢間隙丟失。因此,這種方式雖然效率高但精確度低。圖 1 展示了 MLPX 方式監(jiān)測(cè)事件帶來的誤差(如藍(lán)線所示)。雖然誤差并非嚴(yán)格地隨事件數(shù)目的增加而遞增,但從紅線可以看出,整體上誤差隨著事件數(shù)目的增多而增加。一個(gè)性能計(jì)數(shù)器同時(shí)監(jiān)測(cè)的事件由 10 個(gè)增加到 36 個(gè)時(shí),誤差上升了 46%。如果一個(gè)性能計(jì)數(shù)器同時(shí)承擔(dān)著過多硬件事件數(shù)據(jù)采集的任務(wù),那么將會(huì)導(dǎo)致采集到的數(shù)據(jù)不精確。實(shí)際上,采集全量的硬件事件并非是必須的,許多事件在程序運(yùn)行的全生命周期中并未發(fā)生,時(shí)間序列上表現(xiàn)為全部 0 值。
圖1 多路復(fù)用方式監(jiān)測(cè)事件帶來的誤差Fig. 1 The error variation with the number of events by multiplexing method
為了確保數(shù)據(jù)精確可靠,本文采用另一種監(jiān)測(cè)方式——OCOE 方式進(jìn)行 CPU 性能數(shù)據(jù)的監(jiān)測(cè)。OCOE 方式規(guī)定每次測(cè)量時(shí),一個(gè)性能計(jì)數(shù)器只承擔(dān)一個(gè)硬件事件的監(jiān)測(cè)任務(wù),從負(fù)載程序開始運(yùn)行到結(jié)束。測(cè)量更多事件時(shí),需要重新運(yùn)行負(fù)載,同時(shí)修改每個(gè)性能計(jì)數(shù)器對(duì)應(yīng)的硬件事件。因此,OCOE 方式監(jiān)測(cè)性能耗時(shí)較長(zhǎng),但結(jié)果精確度較高,能完整地保留每個(gè)事件的時(shí)間序列變化情況。
云環(huán)境下存在多個(gè)角色不同的服務(wù)器節(jié)點(diǎn),如主節(jié)點(diǎn)和從節(jié)點(diǎn),它們承擔(dān)著不同的任務(wù)。本研究使用基準(zhǔn)測(cè)試程序來運(yùn)行分布式大數(shù)據(jù)分析負(fù)載,同時(shí)使用性能計(jì)數(shù)器來收集每個(gè)節(jié)點(diǎn)上不同硬件事件在工作負(fù)載運(yùn)行期間的 CPU 性能數(shù)據(jù)。最后將這些原始 CPU 性能數(shù)據(jù)整合到統(tǒng)一的數(shù)據(jù)集中,以便進(jìn)行下一步的數(shù)據(jù)處理。
數(shù)據(jù)收集從工作負(fù)載開始運(yùn)行開始,以 1 s的采樣頻率記錄數(shù)據(jù),直到負(fù)載運(yùn)行結(jié)束。本實(shí)驗(yàn)共記錄 229 個(gè)硬件事件(由于本研究采用的處理器是 Haswell 架構(gòu))和每時(shí)鐘周期機(jī)器指令數(shù)(Instruction Per Cycle,IPC)。其中,每個(gè)硬件事件可視作一維特征(共 229 維),而 IPC 則作為響應(yīng)變量,在后續(xù)步驟中建立機(jī)器學(xué)習(xí)模型。
許多研究將負(fù)載運(yùn)行一次作為一條實(shí)驗(yàn)樣本,把程序運(yùn)行時(shí)間作為響應(yīng)變量[25,29]。本文把程序一次完整的運(yùn)行視為一個(gè)時(shí)間序列,而不是簡(jiǎn)單地將運(yùn)行過程中各種硬件事件作粗粒度的統(tǒng)計(jì),這樣可以最大限度地保留硬件事件的變化細(xì)節(jié)。另外,硬件事件在采樣過程中時(shí)間粒度細(xì)(采樣頻率為 1 s),在后續(xù)的模型訓(xùn)練中有助于提高精確度。
定義硬件事件空間U。用戶、運(yùn)維者或程序開發(fā)人員運(yùn)行m次實(shí)驗(yàn),每次工作負(fù)載從開始運(yùn)行到結(jié)束的時(shí)間段為ts。則硬件事件信息的時(shí)間序列長(zhǎng)度為t(每秒記錄一次)。在每次實(shí)驗(yàn)中,用戶根據(jù)自己的經(jīng)驗(yàn),選擇一部分他們希望監(jiān)測(cè)的事件同時(shí),本文定義Ei包含的硬件事件數(shù)量為:
那么,一共可以監(jiān)測(cè)到事件子空間為:
這也是后續(xù)模型訓(xùn)練的特征空間。
事實(shí)上,每次實(shí)驗(yàn)中,負(fù)載程序的運(yùn)行時(shí)長(zhǎng)并不確定,但在某個(gè)值上、下波動(dòng)。圖 2 為K-means 和 Wordcount 這兩個(gè)負(fù)載在相同實(shí)驗(yàn)環(huán)境下多次運(yùn)行的執(zhí)行時(shí)間變化。其中,K-means的平均運(yùn)行時(shí)長(zhǎng)為 180.08 s,方差為 210.68 s;Wordcount 的平均運(yùn)行時(shí)長(zhǎng)為 99.92 s,方差為769.94 s。這也解釋了每次實(shí)驗(yàn)中 IPC 序列的變化并不完全一致,趨勢(shì)一致但值不一致的原因。同時(shí)又考慮到每次用戶選擇監(jiān)測(cè)的事件可能有重疊。這些現(xiàn)象造成了數(shù)據(jù)不對(duì)齊的問題。所以,m次實(shí)驗(yàn)所得的全部數(shù)據(jù)需要進(jìn)行整合與拼接。
圖2 負(fù)載應(yīng)用 K-means 與 Wordcount 的運(yùn)行時(shí)間波動(dòng)情況Fig. 2 Execution time fl uctuation on K-means and Wordcount
圖 3 展示了如何將每輪運(yùn)行負(fù)載所產(chǎn)生的CPU 性能數(shù)據(jù)整合在一起。其中,圖 3(a)是 3次獨(dú)立實(shí)驗(yàn)產(chǎn)生的數(shù)據(jù),垂直方向表示時(shí)間序列的長(zhǎng)度,水平方向表示事件集的維度(多少個(gè)監(jiān)測(cè)事件)。它們展示了一種典型的事件重疊的情況。其中,黃色豎條代表事件e1產(chǎn)生的時(shí)間序列,它分別在第i次和第k次實(shí)驗(yàn)中被監(jiān)測(cè),即且橙色豎條代表事件e2產(chǎn)生的時(shí)間序列,它分別在第j次和第k次實(shí)驗(yàn)中被監(jiān)測(cè),
隨后,將每次實(shí)驗(yàn)產(chǎn)生的數(shù)據(jù)(除 IPC 外)按對(duì)角線方向依次拼接在一起。而 IPC 序列頭尾拼接,作為最終數(shù)據(jù)集的響應(yīng)變量,如圖 3(b)所示。接著,重復(fù)出現(xiàn)的事件(如e1和e2)序列依次平移至同一列上。最后,將其他位置填 0,如圖 3(c)所示。經(jīng)過m次實(shí)驗(yàn),數(shù)據(jù)合并成一個(gè)的矩陣S,其中,如此形成的矩陣是一個(gè)分塊的、稀疏的大矩陣。其中,矩陣中每一列代表一個(gè)性能事件,每一行代表一次采樣,每一個(gè)分塊代表負(fù)載完整運(yùn)行一次。
圖3 數(shù)據(jù)融合Fig. 3 Data integration
接下來,本文繼續(xù)對(duì)矩陣S中的數(shù)據(jù)做預(yù)處理。不同硬件事件的取值范圍不同,且差異很大。例如,MEM_UOPS_RETIRED.STLB_MISS_LOADS 的范圍是 0~4;而 UOPS_EXECUTED_PORT.PORT_1 的范圍是 96~305。如果一個(gè)事件的取值方差遠(yuǎn)大于另一個(gè)事件,前者會(huì)對(duì)最后生成的估計(jì)模型占主導(dǎo)作用,這個(gè)模型將很難從后者中準(zhǔn)確地評(píng)估到期待的價(jià)值。所以本文采用公式(3)的方法對(duì)其做歸一化處理,使取值范圍全部落在[0,1]內(nèi)。
在機(jī)器學(xué)習(xí)領(lǐng)域,“特征工程”的思想為我們約簡(jiǎn)硬件事件空間的工作帶來了靈感。對(duì)高維硬件事件進(jìn)行數(shù)據(jù)過濾,使得可在低維空間內(nèi)對(duì)其進(jìn)行分析。本方法自動(dòng)選擇出一個(gè)對(duì) IPC 影響最大的事件子集,并對(duì)其進(jìn)行排序。相比特征工程問題來說,本工作就是將每個(gè)硬件事件視為一個(gè)特征,將 IPC 視為目標(biāo),構(gòu)建機(jī)器學(xué)習(xí)模型擬合目標(biāo),并對(duì)每個(gè)特征進(jìn)行重要性量化,最后對(duì)其進(jìn)行排序。
本文選用梯度提升回歸樹算法[30]作為事件選擇的基本模型,在模型的構(gòu)造過程中逐漸計(jì)算出每個(gè)事件的重要性。同時(shí)經(jīng)過硬件事件選擇,每次減少 10 個(gè)最不重要的事件,多次迭代建模,直到模型誤差最小。此時(shí)的事件重要性排序最準(zhǔn)確。
分析硬件事件的重要性,量化研究對(duì)性能影響較大的硬件事件(單個(gè)或多個(gè)),從而幫助理解復(fù)雜情況下的程序性能行為。為了量化硬件事件的重要性,本文構(gòu)造了一個(gè)以 IPC 為目標(biāo)的機(jī)器學(xué)習(xí)模型。該模型的輸入為硬件事件在負(fù)載運(yùn)行期間的時(shí)間序列值,模型輸出為 IPC 的時(shí)間序列,可用公式(4)表示。
其中,IPC為負(fù)載程序運(yùn)行期間以 1 s 為采樣頻率采集到的每時(shí)鐘周期機(jī)器指令數(shù);ei為第i個(gè)硬件事件;n為硬件事件的數(shù)目。對(duì)于現(xiàn)代處理器來說,硬件事件的數(shù)量成百上千,故帶有如此大量的參數(shù)來構(gòu)建精確的性能模型極具挑戰(zhàn),而簡(jiǎn)單的統(tǒng)計(jì)模型尚不能滿足以上要求。為了解決這個(gè)問題,機(jī)器學(xué)習(xí)算法成為有可能解決高維參數(shù)建模問題的方法。但選擇哪一種機(jī)器學(xué)習(xí)算法是一個(gè)值得研究的問題。本文使用梯度提升回歸樹模型,因?yàn)樗谠S多計(jì)算機(jī)體系結(jié)構(gòu)方向的建模任務(wù)中表現(xiàn)均較好[31,32]。
梯度提升回歸樹是一個(gè)典型的針對(duì)任意可微的損失函數(shù)的提升模型,把弱的模型組合成一個(gè)強(qiáng)的模型,可用于回歸和分類問題。提升樹模型可以表示為以決策樹為基函數(shù)的加法模型,是決策樹的線性組合,稱為集成模型。梯度提升回歸樹支持多種不同的回歸損失函數(shù),本文默認(rèn)回歸損失函數(shù)為最小二乘損失函數(shù),由公式(5)表示。
其中,y為真實(shí)值;為模型預(yù)測(cè)值。
梯度提升回歸樹算法由 Friedman[30]提出并實(shí)現(xiàn),同時(shí)提出了如何估計(jì)預(yù)測(cè)變量的相對(duì)影響。對(duì)于這個(gè)集成模型中一個(gè)單獨(dú)的回歸樹T,本文可以使用作為每個(gè)參數(shù)ej對(duì)目標(biāo)變量(IPC)的影響程度的度量。解釋為ej被選中作為決策樹的節(jié)點(diǎn)進(jìn)行分裂的次數(shù),然后根據(jù)對(duì)分裂結(jié)果的影響程度的平方來加權(quán)[31],具體計(jì)算見公式(6)。
其中,nt為ej被選中作為樹的節(jié)點(diǎn)進(jìn)行分裂的次數(shù);p2(k)為第k次分裂后對(duì)樹模型的性能提升的平方。一般地,p(k)被定義為 IPC 的相對(duì)誤差,即那么對(duì)于全部的回歸樹來說,ej的重要性可以用公式(7)表示。
其中,R為組合模型中樹的個(gè)數(shù);為第m棵樹中ej對(duì) IPC 的影響程度。
為了讓最后的結(jié)果更好理解,本文將每個(gè)變量對(duì)目標(biāo)的貢獻(xiàn)值進(jìn)行歸一化處理,即保證這些值的總和為 100%。其中,數(shù)值越高表示該變量對(duì)目標(biāo)的響應(yīng)更強(qiáng),也意味著這個(gè)硬件事件對(duì)性能的影響更為重要。在獲得每個(gè)硬件事件對(duì)性能的重要性之后,首先對(duì)它們進(jìn)行降序排序,然后將排在最末(最不重要)的 10 個(gè)事件剔除,最后用剩余的事件重新訓(xùn)練模型,具體操作流程如圖4 所示。如此迭代,直到硬件事件的數(shù)量減少到使模型精確度最高。本文將這個(gè)最終的模型稱為最精確性能模型。這么做的原因是硬件事件的信息存在冗余,有些硬件事件對(duì)模型的構(gòu)建會(huì)產(chǎn)生負(fù)面的影響。
圖4 迭代的梯度提升回歸樹模型Fig. 4 Iterative gradient boosting regression treemodel
本文的實(shí)驗(yàn)環(huán)境為 4 臺(tái)戴爾服務(wù)器,其中 1 臺(tái)作為主節(jié)點(diǎn),其余為從節(jié)點(diǎn)。每臺(tái)服務(wù)器配備有 16 核 Intel(R) Xeon(R) CPU E5-2630 v3 @2.4GHz 處理器,處理器微體系結(jié)構(gòu)為 Haswell-E,內(nèi)存大小為 64 GB,32K L1d cache,32K L1i cache,256K L2 cache,20480K L3 cache,硬盤容量 2 TB。服務(wù)器的操作系統(tǒng)為Ubuntu 14.04.5 LTS (GNU/Linux 3.16.0-77-generic x86_64),集群管理系統(tǒng)為 Mesos 1.0,應(yīng)用計(jì)算框架為 Spark 2.2。
本文的基準(zhǔn)測(cè)試工具選用 HiBench[33],并從中挑選了 8 個(gè)典型的負(fù)載作為實(shí)驗(yàn)程序,包括圖分析(Pagerank)、分布式數(shù)據(jù)庫應(yīng)用(Scan、Join 和 Aggregation)、機(jī)器學(xué)習(xí)應(yīng)用(Bayes 和K-means)及微基準(zhǔn)程序(Sort 和 Wordcount)。
系統(tǒng)開發(fā)語言使用 Python 2.7。其中,Python 作為一種易讀、易維護(hù)的高級(jí)編程語言已被大量用戶廣泛使用。同時(shí) Python 具有豐富和強(qiáng)大的庫,本文使用 scikit-learn 0.19.0 機(jī)器學(xué)習(xí)庫[34]來實(shí)現(xiàn)文中用到的梯度提升回歸樹算法。
在最精確性能模型中,本文隨機(jī)選擇 80%的樣本作為訓(xùn)練集,剩余的作為測(cè)試集。圖 5 為8 個(gè)基準(zhǔn)測(cè)試程序在迭代訓(xùn)練過程中模型測(cè)試集上的誤差變化情況。模型誤差的定義如公式(8)所示。其中,IPCmeans為實(shí)際度量值;IPCpred為模型預(yù)測(cè)值。
當(dāng) 229 個(gè)事件全部參與訓(xùn)練時(shí),模型在 8 個(gè)基準(zhǔn)測(cè)試程序下的平均誤差為 14%。而當(dāng)事件數(shù)目減少到 150 個(gè)時(shí),平均誤差下降到了 6.3%。這說明全量的硬件事件確實(shí)存在冗余。
圖 6 為 8 個(gè)基準(zhǔn)測(cè)試程序的硬件事件重要性排序,以及將這 8 個(gè)程序產(chǎn)生的硬件事件時(shí)間序列數(shù)據(jù)合并之后,為整體建模得到的硬件事件重要性排序(Mix)。其中,y軸表示事件重要性(%);x軸為各個(gè)事件名稱的縮寫。事件名稱的全稱和事件含義說明見表 1。由于篇幅有限,圖中只展示了每個(gè)負(fù)載排名前 5 的事件。
圖5 性能事件約簡(jiǎn)過程中模型誤差的變化Fig. 5 Model error varies with the number of events
圖6 8 個(gè)負(fù)載程序單獨(dú)建模及其混合建模后的性能事件重要性排名(前 5)Fig. 6 The importance rank of events for 8 workload models and a hybrid model
表1 事件描述Table 1 Event name and description
下面闡述本研究的重要發(fā)現(xiàn)。首先,同一個(gè)測(cè)試程序中總有 1 個(gè)或 2 個(gè)事件的重要性遠(yuǎn)遠(yuǎn)高于其他事件。例如,在 Aggregation 程序中,MCMO 和 ISIF 是最重要的兩個(gè)事件,它們的重要性都大于 5.8%,而其余事件的重要性都低于3.6%。其次,對(duì)于不同的基準(zhǔn)測(cè)試程序,其最重要的事件是不盡相同的。例如,受 K-means 程序影響最大的硬件事件是 ISIF;而受 Bayes 程序影響最大的硬件事件是 BIEB。這意味著不同的測(cè)試程序在微體系結(jié)構(gòu)層面的特征不一樣。最后,縱觀 8 個(gè) Spark 測(cè)試程序,它們較重要的事件存在交集,說明 Spark 程序之間也存在共同的重要硬件事件。其中,ISIF 和 BIEB 在所有的基準(zhǔn)測(cè)試程序中都很重要。同時(shí),這個(gè)特點(diǎn)也體現(xiàn)在Mix 程序中,一定程度上說明這些結(jié)論得到了佐證。另外, PWI3、MCMO 和 LDRW 在數(shù)據(jù)庫操作相關(guān)的負(fù)載中重要性較高。以上發(fā)現(xiàn)都可以有效地用來指導(dǎo)以 Spark 為例的 in-memory 程序的性能優(yōu)化。
由于目前在研究文獻(xiàn)中尚沒發(fā)現(xiàn)利用硬件事件指導(dǎo)大數(shù)據(jù)框架參數(shù)調(diào)優(yōu)的研究。為驗(yàn)證本文提出的硬件事件重要性排序的效果,我們構(gòu)建了一個(gè)傳統(tǒng)的基于梯度提升回歸樹的 Spark 參數(shù)調(diào)優(yōu)模型,與本文提出的在性能事件重要性指導(dǎo)下的 Spark 參數(shù)調(diào)優(yōu)進(jìn)行對(duì)比。
傳統(tǒng)的 Spark 參數(shù)調(diào)優(yōu)模型[35]將 Spark 配置參數(shù)視為模型的特征,對(duì)這些參數(shù)隨機(jī)設(shè)定參數(shù)值后運(yùn)行負(fù)載,記錄程序完整的運(yùn)行時(shí)間,并將這個(gè)運(yùn)行時(shí)間視為模型的響應(yīng)變量。這個(gè)過程需要構(gòu)造充足的實(shí)驗(yàn)樣本才能讓模型精確,以確定影響程序性能最重要的參數(shù)。另一方面,通過將最精確性能模型得出的排名前 10 的硬件性能事件與 Spark 參數(shù)進(jìn)行關(guān)聯(lián),直接關(guān)注與重要事件緊耦合的 Spark 參數(shù),即可快速得出影響程序性能的重要參數(shù)。基于硬件性能事件重要性指導(dǎo)的 Spark 參數(shù)調(diào)優(yōu)方法的數(shù)據(jù)收集階段與傳統(tǒng)的Spark 參數(shù)配置方法相同。而在訓(xùn)練性能模型階段,我們構(gòu)造事件與 Spark 參數(shù)的混合向量,如公式(9)所示。
其中,e代表事件;p代表 Spark 參數(shù),一般n取10 以內(nèi)。然后將這樣的樣本向量投入機(jī)器學(xué)習(xí)模型中訓(xùn)練,以執(zhí)行時(shí)間作為模型擬合的目標(biāo)變量。
在模型訓(xùn)練過程中,可以找出任一事件和任一 Spark 參數(shù)之間的相關(guān)性。在最緊耦合的一對(duì)事件和參數(shù)中,我們即可確定這個(gè)參數(shù)為調(diào)優(yōu)目標(biāo)。
實(shí)驗(yàn)結(jié)果表明,以 Pagerank 為例,構(gòu)建Spark 參數(shù)模型至少需要構(gòu)建 6 000 組訓(xùn)練樣本(6 000 次程序運(yùn)行)才能有效地找出最重要的參數(shù)。而訓(xùn)練最精確性能模型本身需要花費(fèi) 3 277條樣本(60 次程序運(yùn)行),計(jì)算排名前 10 的硬件性能事件與 Spark 參數(shù)的耦合程度需要構(gòu)造 1 520條樣本,如表 2 所示。而二者最終確定的重要Spark 參數(shù)一致。
表2 模型結(jié)果對(duì)比Table 2 Comparison of model results
由此可以發(fā)現(xiàn),最精確性能模型方法的性能優(yōu)于傳統(tǒng)的基于機(jī)器學(xué)習(xí)方法的 Spark 參數(shù)調(diào)優(yōu)性能。但是,受到負(fù)載程序運(yùn)行時(shí)間有限的影響,最精確性能模型的精度略低于對(duì) Spark 參數(shù)直接建模。所以在對(duì)精度要求高的任務(wù)中,二者可以互補(bǔ),先由最精確性能模型快速選出大致的調(diào)參范圍,再建立這些參數(shù)的機(jī)器學(xué)習(xí)模型,更精確地得出具體的調(diào)參對(duì)象。
由性能計(jì)數(shù)器記錄的性能監(jiān)測(cè)數(shù)據(jù),能夠很好地洞察云計(jì)算負(fù)載的性能表現(xiàn)。本文提出一種CPU 性能大數(shù)據(jù)的挖掘方法,通過迭代使用梯度提升回歸樹算法構(gòu)建性能模型,分析出云環(huán)境下負(fù)載的性能事件重要性排序,從而指導(dǎo)云平臺(tái)的性能調(diào)優(yōu)。
由于終端用戶很少擁有關(guān)于系統(tǒng)底層和性能事件的領(lǐng)域知識(shí),這讓用戶對(duì)使用相關(guān)的性能分析工具造成了障礙。本文提出的最精確性能模型,通過對(duì)事件受 IPC 影響的重要程度排序來降低事件空間。這種方法使得用戶不需要完全了解幾百個(gè)全部事件的含義,只需要熟悉掌握個(gè)別少數(shù)事件,就能快速分析系統(tǒng)性能,參與性能調(diào)優(yōu)。文中還實(shí)現(xiàn)并分析了一個(gè)對(duì) Spark 配置參數(shù)調(diào)優(yōu)的案例,這個(gè)案例很好地將硬件層和應(yīng)用層結(jié)合在一起。
盡管本文獲得了一定的成果,但仍存在一些不足之處。首先,OCOE 方式收集性能數(shù)據(jù)記錄始終效率較低,數(shù)據(jù)準(zhǔn)備過程時(shí)間較長(zhǎng)。在后續(xù)研究中,可以使用統(tǒng)計(jì)機(jī)器學(xué)習(xí)領(lǐng)域的一些方法對(duì) MLPX 方式監(jiān)測(cè)到的性能數(shù)據(jù)進(jìn)行數(shù)據(jù)清洗,提高數(shù)據(jù)質(zhì)量。由此,解決了 MLPX 方式監(jiān)測(cè)數(shù)據(jù)帶來的誤差,使得性能監(jiān)測(cè)過程既提高了效率,又保證了數(shù)據(jù)的可靠準(zhǔn)確。其次,除了本文所述的關(guān)注事件受性能影響的重要程度,量化研究事件與事件之間的相互影響程度也十分必要。綜合利用事件重要性排名和事件之間的相關(guān)性可用于快速優(yōu)化大數(shù)據(jù)分析程序的性能。