呂依蓉 孫 斌 喻之斌

1(中國科學院深圳先進技術研究院 深圳 518055)

2(中國科學院大學 北京 100049)

3(首都師范大學信息工程學院 北京 100048)

1 引 言

隨著云計算的發(fā)展，數(shù)據(jù)中心作為計算和存儲的核心在運維管理方面遇到了諸多問題和挑戰(zhàn)。為了分析、優(yōu)化程序以及有效地管理系統(tǒng)資源，程序員和系統(tǒng)運維人員都需要精確獲取系統(tǒng)運行時的底層信息。性能計數(shù)器是用于硬件事件計數(shù)的一類寄存器，它們可以在時鐘周期級別、低代價地監(jiān)測并記錄系統(tǒng)運行中產(chǎn)生的各類硬件事件。這些性能事件隨著時間推移可以輕易地產(chǎn)生大量數(shù)據(jù)。 在云計算的環(huán)境下，數(shù)以千計的服務器和數(shù)以億計的負載應用使硬件事件數(shù)據(jù)量更大，如谷歌的云平臺每天產(chǎn)生幾個 GB甚至幾個 TB 的中央處理器(Central Processing Unit，CPU)性能數(shù)據(jù)，我們稱之為處理器性能大數(shù)據(jù)。這些性能事件實際上隱含著影響云計算負載性能的關鍵因素。因此，性能計數(shù)器和硬件性能事件被廣泛地應用在任務調(diào)度[1,2]、負載特征刻畫[3-10]、編譯器優(yōu)化[11-13]和體系結構優(yōu)化[14-17]等方面。與此同時，一系列基于性能計數(shù)器的軟件工具也應運而生，如 perf_event[18]、PAPI[19]、VTune 和 Oprof i le[20]等。

在云計算時代，性能計數(shù)器變得更加重要。許多云服務提供商都渴望通過性能計數(shù)器來理解云服務的性能瓶頸。這是因為即使少量的性能提升(如1%)也能帶來巨大的經(jīng)濟效益(如數(shù)百萬美元)[3]。

然而，在云計算時代使用 CPU 性能計數(shù)器產(chǎn)生的數(shù)據(jù)面臨著一個新的挑戰(zhàn)——海量的、無規(guī)律的 CPU 性能數(shù)據(jù)難以理解。谷歌的工程師曾報告[3]他們每天通過 GWP 工具從谷歌的數(shù)據(jù)中心收集幾個 GB 的 CPU 性能數(shù)據(jù)。如果將一個硬件事件視為一個維度，這些數(shù)據(jù)將是非常高維的數(shù)據(jù)。例如，因特爾的 Haswell 架構規(guī)定了 229 個性能事件，則這款處理器的性能數(shù)據(jù)有229 維[21]；因特爾的 IvyTown 架構規(guī)定了 1 423 個性能事件，則 IvyTown 的性能數(shù)據(jù)有 1 423 維[22]。如果同等對待每個事件產(chǎn)生的數(shù)據(jù)，則需要付出巨大的努力來處理、分析和利用 CPU 性能大數(shù)據(jù)。為了方便對性能數(shù)據(jù)進行分析，需要通過以下 3 個方面：(1)量化性能事件對性能的重要性；(2)發(fā)現(xiàn)事件與性能的聯(lián)系；(3)理解事件之間的相互作用。然而，這 3 個方面還未曾在計算機系統(tǒng)結構和云計算系統(tǒng)中進行研究。

因此，本文提出一種云平臺上的 CPU 性能大數(shù)據(jù)挖掘方法，借助性能計數(shù)器性能監(jiān)測工具，對大量硬件事件進行性能重要性排序，尋找事件模式，從而有效地度量和理解云平臺上的性能大數(shù)據(jù)。本文的主要貢獻如下：

(1)單計數(shù)器單事件(One Counter One Event，OCOE)方式下性能監(jiān)測數(shù)據(jù)的拼接與整合。由于性能監(jiān)測數(shù)據(jù)無法一次性測量，因此數(shù)據(jù)片段首先需要進行融合。而多組測量數(shù)據(jù)之間可能出現(xiàn)事件集重疊的現(xiàn)象，造成了數(shù)據(jù)不對齊的問題。本文通過設計并實現(xiàn)了 CPU 性能數(shù)據(jù)融合的方法。

(2)性能事件對性能的重要性量化。用來采集硬件事件信息的性能計數(shù)器數(shù)量是有限的，而且用戶往往并不需要利用所有的硬件事件，即只需要少數(shù)重要的硬件事件便可以分析負載特征并進行性能優(yōu)化。本文首先提出基于機器學習的硬件事件重要性量化方法，然后再用迭代排序不斷約簡事件空間，最后提煉出一組重要的事件。

本文采用 8 個 Apache Spark 程序進行實驗，所建模型在測試集上的精度達到了 95%。另外，我們還用此方法精確刻畫了不同的 Spark 程序之間的個性與共性特征。

2 研究背景

現(xiàn)代處理器一般集成了 4～8 個性能計數(shù)器[21,23]。其中，性能計數(shù)器是一類用在時鐘周期級別測量處理器性能事件的特殊寄存器。性能事件是指可由性能計數(shù)器測量的、處理器內(nèi)的硬件事件，如時鐘周期數(shù)、執(zhí)行的指令數(shù)以及各級高速緩存的命中次數(shù)等[24]。此類硬件事件種類豐富、功能齊全，不僅可以進行實時監(jiān)測，還可以精確到時鐘周期級別。有的事件還被細分成更細粒度的子事件，如高速緩存缺失事件可以被分為數(shù)據(jù)讀取階段的缺失、數(shù)據(jù)寫入階段的缺失、取指令階段的缺失及指令預取階段的缺失等[25]。系統(tǒng)所支持的事件因處理器而異，不同的供應商會提供不同的硬件事件集；甚至同一處理供應商為不同架構的處理器提供不同數(shù)量的硬件事件。一般來說，處理器能支持數(shù)百個硬件事件。例如，因特爾為 Haswell 架構的處理器提供了 229個硬件事件[21]，而為 IvyTown 架構的處理器提供了 1 423 個硬件事件[22]。

通過實時監(jiān)測硬件事件，可以分析程序運行時的行為，從而獲得負載的性能、功耗和能效等特征。而這些特征可以作為資源調(diào)整、任務調(diào)度策略的依據(jù)，最終達到優(yōu)化能效的目的。

然而，性能計數(shù)器在使用過程中面臨著一個重大挑戰(zhàn)：可用的計數(shù)器數(shù)目相對保持固定，但需要監(jiān)測的性能事件的數(shù)目卻愈發(fā)增多，遠遠大于可用的計數(shù)器數(shù)目。

少量的性能計數(shù)器和大量的待監(jiān)測性能事件使監(jiān)測效率和監(jiān)測結果準確度之間出現(xiàn)了矛盾。為了提高效率，很多研究采用多路復用(Multiplexing，MLPX)的監(jiān)測方式[26-28]。采用MLPX 方式時，只需要完整地運行負載程序一次，期間每個性能計數(shù)器通過輪詢的方式監(jiān)測多個硬件事件。最后，每個硬件事件根據(jù)被記錄到的片段推算出在負載整個運行期間的表現(xiàn)。由于每個硬件事件只在負載程序運行過程中的一部分時間內(nèi)被監(jiān)測到，導致其性能表現(xiàn)在最終的結果數(shù)據(jù)中并未被完全體現(xiàn)出來，許多關鍵信息也許會在輪詢間隙丟失。因此，這種方式雖然效率高但精確度低。圖 1 展示了 MLPX 方式監(jiān)測事件帶來的誤差(如藍線所示)。雖然誤差并非嚴格地隨事件數(shù)目的增加而遞增，但從紅線可以看出，整體上誤差隨著事件數(shù)目的增多而增加。一個性能計數(shù)器同時監(jiān)測的事件由 10 個增加到 36 個時，誤差上升了 46%。如果一個性能計數(shù)器同時承擔著過多硬件事件數(shù)據(jù)采集的任務，那么將會導致采集到的數(shù)據(jù)不精確。實際上，采集全量的硬件事件并非是必須的，許多事件在程序運行的全生命周期中并未發(fā)生，時間序列上表現(xiàn)為全部 0 值。

圖1 多路復用方式監(jiān)測事件帶來的誤差Fig. 1 The error variation with the number of events by multiplexing method

為了確保數(shù)據(jù)精確可靠，本文采用另一種監(jiān)測方式——OCOE 方式進行 CPU 性能數(shù)據(jù)的監(jiān)測。OCOE 方式規(guī)定每次測量時，一個性能計數(shù)器只承擔一個硬件事件的監(jiān)測任務，從負載程序開始運行到結束。測量更多事件時，需要重新運行負載，同時修改每個性能計數(shù)器對應的硬件事件。因此，OCOE 方式監(jiān)測性能耗時較長，但結果精確度較高，能完整地保留每個事件的時間序列變化情況。

3 CPU 性能監(jiān)測數(shù)據(jù)方法

3.1 數(shù)據(jù)融合和預處理

云環(huán)境下存在多個角色不同的服務器節(jié)點，如主節(jié)點和從節(jié)點，它們承擔著不同的任務。本研究使用基準測試程序來運行分布式大數(shù)據(jù)分析負載，同時使用性能計數(shù)器來收集每個節(jié)點上不同硬件事件在工作負載運行期間的 CPU 性能數(shù)據(jù)。最后將這些原始 CPU 性能數(shù)據(jù)整合到統(tǒng)一的數(shù)據(jù)集中，以便進行下一步的數(shù)據(jù)處理。

數(shù)據(jù)收集從工作負載開始運行開始，以 1 s的采樣頻率記錄數(shù)據(jù)，直到負載運行結束。本實驗共記錄 229 個硬件事件(由于本研究采用的處理器是 Haswell 架構)和每時鐘周期機器指令數(shù)(Instruction Per Cycle，IPC)。其中，每個硬件事件可視作一維特征(共 229 維)，而 IPC 則作為響應變量，在后續(xù)步驟中建立機器學習模型。

許多研究將負載運行一次作為一條實驗樣本，把程序運行時間作為響應變量[25,29]。本文把程序一次完整的運行視為一個時間序列，而不是簡單地將運行過程中各種硬件事件作粗粒度的統(tǒng)計，這樣可以最大限度地保留硬件事件的變化細節(jié)。另外，硬件事件在采樣過程中時間粒度細(采樣頻率為 1 s)，在后續(xù)的模型訓練中有助于提高精確度。

定義硬件事件空間U。用戶、運維者或程序開發(fā)人員運行m次實驗，每次工作負載從開始運行到結束的時間段為ts。則硬件事件信息的時間序列長度為t(每秒記錄一次)。在每次實驗中，用戶根據(jù)自己的經(jīng)驗，選擇一部分他們希望監(jiān)測的事件同時，本文定義Ei包含的硬件事件數(shù)量為：

那么，一共可以監(jiān)測到事件子空間為：

這也是后續(xù)模型訓練的特征空間。

事實上，每次實驗中，負載程序的運行時長并不確定，但在某個值上、下波動。圖 2 為K-means 和 Wordcount 這兩個負載在相同實驗環(huán)境下多次運行的執(zhí)行時間變化。其中，K-means的平均運行時長為 180.08 s，方差為 210.68 s；Wordcount 的平均運行時長為 99.92 s，方差為769.94 s。這也解釋了每次實驗中 IPC 序列的變化并不完全一致，趨勢一致但值不一致的原因。同時又考慮到每次用戶選擇監(jiān)測的事件可能有重疊。這些現(xiàn)象造成了數(shù)據(jù)不對齊的問題。所以，m次實驗所得的全部數(shù)據(jù)需要進行整合與拼接。

圖2 負載應用 K-means 與 Wordcount 的運行時間波動情況Fig. 2 Execution time fl uctuation on K-means and Wordcount

圖 3 展示了如何將每輪運行負載所產(chǎn)生的CPU 性能數(shù)據(jù)整合在一起。其中，圖 3(a)是 3次獨立實驗產(chǎn)生的數(shù)據(jù)，垂直方向表示時間序列的長度，水平方向表示事件集的維度(多少個監(jiān)測事件)。它們展示了一種典型的事件重疊的情況。其中，黃色豎條代表事件e1產(chǎn)生的時間序列，它分別在第i次和第k次實驗中被監(jiān)測，即且橙色豎條代表事件e2產(chǎn)生的時間序列，它分別在第j次和第k次實驗中被監(jiān)測，

隨后，將每次實驗產(chǎn)生的數(shù)據(jù)(除 IPC 外)按對角線方向依次拼接在一起。而 IPC 序列頭尾拼接，作為最終數(shù)據(jù)集的響應變量，如圖 3(b)所示。接著，重復出現(xiàn)的事件(如e1和e2)序列依次平移至同一列上。最后，將其他位置填 0，如圖 3(c)所示。經(jīng)過m次實驗，數(shù)據(jù)合并成一個的矩陣S，其中，如此形成的矩陣是一個分塊的、稀疏的大矩陣。其中，矩陣中每一列代表一個性能事件，每一行代表一次采樣，每一個分塊代表負載完整運行一次。

圖3 數(shù)據(jù)融合Fig. 3 Data integration

接下來，本文繼續(xù)對矩陣S中的數(shù)據(jù)做預處理。不同硬件事件的取值范圍不同，且差異很大。例如，MEM_UOPS_RETIRED.STLB_MISS_LOADS 的范圍是 0～4；而 UOPS_EXECUTED_PORT.PORT_1 的范圍是 96～305。如果一個事件的取值方差遠大于另一個事件，前者會對最后生成的估計模型占主導作用，這個模型將很難從后者中準確地評估到期待的價值。所以本文采用公式(3)的方法對其做歸一化處理，使取值范圍全部落在[0,1]內(nèi)。

3.2 基于迭代梯度提升樹模型的特征選擇方法

在機器學習領域，“特征工程”的思想為我們約簡硬件事件空間的工作帶來了靈感。對高維硬件事件進行數(shù)據(jù)過濾，使得可在低維空間內(nèi)對其進行分析。本方法自動選擇出一個對 IPC 影響最大的事件子集，并對其進行排序。相比特征工程問題來說，本工作就是將每個硬件事件視為一個特征，將 IPC 視為目標，構建機器學習模型擬合目標，并對每個特征進行重要性量化，最后對其進行排序。

本文選用梯度提升回歸樹算法[30]作為事件選擇的基本模型，在模型的構造過程中逐漸計算出每個事件的重要性。同時經(jīng)過硬件事件選擇，每次減少 10 個最不重要的事件，多次迭代建模，直到模型誤差最小。此時的事件重要性排序最準確。

分析硬件事件的重要性，量化研究對性能影響較大的硬件事件(單個或多個)，從而幫助理解復雜情況下的程序性能行為。為了量化硬件事件的重要性，本文構造了一個以 IPC 為目標的機器學習模型。該模型的輸入為硬件事件在負載運行期間的時間序列值，模型輸出為 IPC 的時間序列，可用公式(4)表示。

其中，IPC為負載程序運行期間以 1 s 為采樣頻率采集到的每時鐘周期機器指令數(shù)；ei為第i個硬件事件；n為硬件事件的數(shù)目。對于現(xiàn)代處理器來說，硬件事件的數(shù)量成百上千，故帶有如此大量的參數(shù)來構建精確的性能模型極具挑戰(zhàn)，而簡單的統(tǒng)計模型尚不能滿足以上要求。為了解決這個問題，機器學習算法成為有可能解決高維參數(shù)建模問題的方法。但選擇哪一種機器學習算法是一個值得研究的問題。本文使用梯度提升回歸樹模型，因為它在許多計算機體系結構方向的建模任務中表現(xiàn)均較好[31,32]。

梯度提升回歸樹是一個典型的針對任意可微的損失函數(shù)的提升模型，把弱的模型組合成一個強的模型，可用于回歸和分類問題。提升樹模型可以表示為以決策樹為基函數(shù)的加法模型，是決策樹的線性組合，稱為集成模型。梯度提升回歸樹支持多種不同的回歸損失函數(shù)，本文默認回歸損失函數(shù)為最小二乘損失函數(shù)，由公式(5)表示。

其中，y為真實值；為模型預測值。

梯度提升回歸樹算法由 Friedman[30]提出并實現(xiàn)，同時提出了如何估計預測變量的相對影響。對于這個集成模型中一個單獨的回歸樹T，本文可以使用作為每個參數(shù)ej對目標變量(IPC)的影響程度的度量。解釋為ej被選中作為決策樹的節(jié)點進行分裂的次數(shù)，然后根據(jù)對分裂結果的影響程度的平方來加權[31]，具體計算見公式(6)。

其中，nt為ej被選中作為樹的節(jié)點進行分裂的次數(shù)；p2(k)為第k次分裂后對樹模型的性能提升的平方。一般地，p(k)被定義為 IPC 的相對誤差，即那么對于全部的回歸樹來說，ej的重要性可以用公式(7)表示。

其中，R為組合模型中樹的個數(shù)；為第m棵樹中ej對 IPC 的影響程度。

為了讓最后的結果更好理解，本文將每個變量對目標的貢獻值進行歸一化處理，即保證這些值的總和為 100%。其中，數(shù)值越高表示該變量對目標的響應更強，也意味著這個硬件事件對性能的影響更為重要。在獲得每個硬件事件對性能的重要性之后，首先對它們進行降序排序，然后將排在最末(最不重要)的 10 個事件剔除，最后用剩余的事件重新訓練模型，具體操作流程如圖4 所示。如此迭代，直到硬件事件的數(shù)量減少到使模型精確度最高。本文將這個最終的模型稱為最精確性能模型。這么做的原因是硬件事件的信息存在冗余，有些硬件事件對模型的構建會產(chǎn)生負面的影響。

圖4 迭代的梯度提升回歸樹模型Fig. 4 Iterative gradient boosting regression treemodel

4 實驗結果與分析

4.1 實驗環(huán)境

本文的實驗環(huán)境為 4 臺戴爾服務器，其中 1 臺作為主節(jié)點，其余為從節(jié)點。每臺服務器配備有 16 核 Intel(R) Xeon(R) CPU E5-2630 v3 @2.4GHz 處理器，處理器微體系結構為 Haswell-E，內(nèi)存大小為 64 GB，32K L1d cache，32K L1i cache，256K L2 cache，20480K L3 cache，硬盤容量 2 TB。服務器的操作系統(tǒng)為Ubuntu 14.04.5 LTS (GNU/Linux 3.16.0-77-generic x86_64)，集群管理系統(tǒng)為 Mesos 1.0，應用計算框架為 Spark 2.2。

本文的基準測試工具選用 HiBench[33]，并從中挑選了 8 個典型的負載作為實驗程序，包括圖分析(Pagerank)、分布式數(shù)據(jù)庫應用(Scan、Join 和 Aggregation)、機器學習應用(Bayes 和K-means)及微基準程序(Sort 和 Wordcount)。

系統(tǒng)開發(fā)語言使用 Python 2.7。其中，Python 作為一種易讀、易維護的高級編程語言已被大量用戶廣泛使用。同時 Python 具有豐富和強大的庫，本文使用 scikit-learn 0.19.0 機器學習庫[34]來實現(xiàn)文中用到的梯度提升回歸樹算法。

4.2 模型精度評估

在最精確性能模型中，本文隨機選擇 80%的樣本作為訓練集，剩余的作為測試集。圖 5 為8 個基準測試程序在迭代訓練過程中模型測試集上的誤差變化情況。模型誤差的定義如公式(8)所示。其中，IPCmeans為實際度量值；IPCpred為模型預測值。

當 229 個事件全部參與訓練時，模型在 8 個基準測試程序下的平均誤差為 14%。而當事件數(shù)目減少到 150 個時，平均誤差下降到了 6.3%。這說明全量的硬件事件確實存在冗余。

4.3 性能事件重要性

圖 6 為 8 個基準測試程序的硬件事件重要性排序，以及將這 8 個程序產(chǎn)生的硬件事件時間序列數(shù)據(jù)合并之后，為整體建模得到的硬件事件重要性排序(Mix)。其中，y軸表示事件重要性(%)；x軸為各個事件名稱的縮寫。事件名稱的全稱和事件含義說明見表 1。由于篇幅有限，圖中只展示了每個負載排名前 5 的事件。

圖5 性能事件約簡過程中模型誤差的變化Fig. 5 Model error varies with the number of events

圖6 8 個負載程序單獨建模及其混合建模后的性能事件重要性排名(前 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)。首先，同一個測試程序中總有 1 個或 2 個事件的重要性遠遠高于其他事件。例如，在 Aggregation 程序中，MCMO 和 ISIF 是最重要的兩個事件，它們的重要性都大于 5.8%，而其余事件的重要性都低于3.6%。其次，對于不同的基準測試程序，其最重要的事件是不盡相同的。例如，受 K-means 程序影響最大的硬件事件是 ISIF；而受 Bayes 程序影響最大的硬件事件是 BIEB。這意味著不同的測試程序在微體系結構層面的特征不一樣。最后，縱觀 8 個 Spark 測試程序，它們較重要的事件存在交集，說明 Spark 程序之間也存在共同的重要硬件事件。其中，ISIF 和 BIEB 在所有的基準測試程序中都很重要。同時，這個特點也體現(xiàn)在Mix 程序中，一定程度上說明這些結論得到了佐證。另外， PWI3、MCMO 和 LDRW 在數(shù)據(jù)庫操作相關的負載中重要性較高。以上發(fā)現(xiàn)都可以有效地用來指導以 Spark 為例的 in-memory 程序的性能優(yōu)化。

由于目前在研究文獻中尚沒發(fā)現(xiàn)利用硬件事件指導大數(shù)據(jù)框架參數(shù)調(diào)優(yōu)的研究。為驗證本文提出的硬件事件重要性排序的效果，我們構建了一個傳統(tǒng)的基于梯度提升回歸樹的 Spark 參數(shù)調(diào)優(yōu)模型，與本文提出的在性能事件重要性指導下的 Spark 參數(shù)調(diào)優(yōu)進行對比。

傳統(tǒng)的 Spark 參數(shù)調(diào)優(yōu)模型[35]將 Spark 配置參數(shù)視為模型的特征，對這些參數(shù)隨機設定參數(shù)值后運行負載，記錄程序完整的運行時間，并將這個運行時間視為模型的響應變量。這個過程需要構造充足的實驗樣本才能讓模型精確，以確定影響程序性能最重要的參數(shù)。另一方面，通過將最精確性能模型得出的排名前 10 的硬件性能事件與 Spark 參數(shù)進行關聯(lián)，直接關注與重要事件緊耦合的 Spark 參數(shù)，即可快速得出影響程序性能的重要參數(shù)?；谟布阅苁录匾灾笇У?Spark 參數(shù)調(diào)優(yōu)方法的數(shù)據(jù)收集階段與傳統(tǒng)的Spark 參數(shù)配置方法相同。而在訓練性能模型階段，我們構造事件與 Spark 參數(shù)的混合向量，如公式(9)所示。

其中，e代表事件；p代表 Spark 參數(shù)，一般n取10 以內(nèi)。然后將這樣的樣本向量投入機器學習模型中訓練，以執(zhí)行時間作為模型擬合的目標變量。

在模型訓練過程中，可以找出任一事件和任一 Spark 參數(shù)之間的相關性。在最緊耦合的一對事件和參數(shù)中，我們即可確定這個參數(shù)為調(diào)優(yōu)目標。

實驗結果表明，以 Pagerank 為例，構建Spark 參數(shù)模型至少需要構建 6 000 組訓練樣本(6 000 次程序運行)才能有效地找出最重要的參數(shù)。而訓練最精確性能模型本身需要花費 3 277條樣本(60 次程序運行)，計算排名前 10 的硬件性能事件與 Spark 參數(shù)的耦合程度需要構造 1 520條樣本，如表 2 所示。而二者最終確定的重要Spark 參數(shù)一致。

表2 模型結果對比Table 2 Comparison of model results

由此可以發(fā)現(xiàn)，最精確性能模型方法的性能優(yōu)于傳統(tǒng)的基于機器學習方法的 Spark 參數(shù)調(diào)優(yōu)性能。但是，受到負載程序運行時間有限的影響，最精確性能模型的精度略低于對 Spark 參數(shù)直接建模。所以在對精度要求高的任務中，二者可以互補，先由最精確性能模型快速選出大致的調(diào)參范圍，再建立這些參數(shù)的機器學習模型，更精確地得出具體的調(diào)參對象。

5 總結與展望

由性能計數(shù)器記錄的性能監(jiān)測數(shù)據(jù)，能夠很好地洞察云計算負載的性能表現(xiàn)。本文提出一種CPU 性能大數(shù)據(jù)的挖掘方法，通過迭代使用梯度提升回歸樹算法構建性能模型，分析出云環(huán)境下負載的性能事件重要性排序，從而指導云平臺的性能調(diào)優(yōu)。

由于終端用戶很少擁有關于系統(tǒng)底層和性能事件的領域知識，這讓用戶對使用相關的性能分析工具造成了障礙。本文提出的最精確性能模型，通過對事件受 IPC 影響的重要程度排序來降低事件空間。這種方法使得用戶不需要完全了解幾百個全部事件的含義，只需要熟悉掌握個別少數(shù)事件，就能快速分析系統(tǒng)性能，參與性能調(diào)優(yōu)。文中還實現(xiàn)并分析了一個對 Spark 配置參數(shù)調(diào)優(yōu)的案例，這個案例很好地將硬件層和應用層結合在一起。

盡管本文獲得了一定的成果，但仍存在一些不足之處。首先，OCOE 方式收集性能數(shù)據(jù)記錄始終效率較低，數(shù)據(jù)準備過程時間較長。在后續(xù)研究中，可以使用統(tǒng)計機器學習領域的一些方法對 MLPX 方式監(jiān)測到的性能數(shù)據(jù)進行數(shù)據(jù)清洗，提高數(shù)據(jù)質(zhì)量。由此，解決了 MLPX 方式監(jiān)測數(shù)據(jù)帶來的誤差，使得性能監(jiān)測過程既提高了效率，又保證了數(shù)據(jù)的可靠準確。其次，除了本文所述的關注事件受性能影響的重要程度，量化研究事件與事件之間的相互影響程度也十分必要。綜合利用事件重要性排名和事件之間的相關性可用于快速優(yōu)化大數(shù)據(jù)分析程序的性能。