676      阿裏雲  技術社區[雲棲]

使用SLS和ODPS進行係統的性能分析

作者：陳昕

在對計算機係統，尤其是分布式係統的搭建和驗證過程中，性能因素是需要著重考慮的因素之一。更激進一點說，判斷架構設計的正確與否，性能的好壞、是否可控、是否可預期絕對是最有效的衡量指標。

不幸的是，現有的性能工具大部分是針對代碼級的運行時間進行分析，目標是診斷代碼的性能bug。但目前我們並沒有（或者我還沒見到）針對大型的分布式係統的係統級性能分析工具。

雖然這樣，但我們可以發揚DIY精神，卷起袖子自己來做這樣的性能分析。通過簡單日誌服務(SLS)對性能日誌進行收集，並使用SLS的離線通道將性能相關的數據導入ODPS中，再拿出專業的數據分析工具R語言，就能夠做任意的性能分析了。隻有想不到，沒有做不到！

我們就以OXS場景來作背景，來看看不同時刻從OXS前端機發送到XXEngine的XXServer的請求是否均勻，是否有熱點，熱點是如何轉移的，以及對性能的影響。從這個很有現實意義的例子來看看如何使用這樣的方法來進行性能分析。

記錄性能日誌

所謂“巧婦難為無米之炊”，在性能分析的第一步一定要準備性能數據。在係統中打出一條性能日誌應該是代價很小的一種方案。

對於飛天來說，在代碼中添加一條性能日誌也十分容易。飛天的日誌可以采用異步的方式打出，所以幾乎不會影響原有係統的性能。日誌中最好記錄一些與性能相關的數據和信息。如在XXServer 中就會記錄如下的性能日誌：

上述日誌中記錄了當時的時間點、請求類型、請求到達的時間點、在隊列中等待的時間、係統處理這個請求的時間等有用的信息。

注意：為了收集日誌的方便，最好單獨將性能日誌輸出到一個日誌文件中。

用SLS收集日誌

性能日誌如果可以正常生成，就可以配置SLS收集這些日誌了。這篇文檔（SLS控製台操作指南）詳細講述了如何配置SLS進行日誌收集，這裏就不再贅述了。

日誌如果正常收集，可以從SLS的控製台上看到：

使用SLS的離線導入功能寫入ODPS

在日誌收集完成後，就能夠用SLS的離線導入功能導入ODPS中，將這些數據持久化下來，也為之後的離線分析做準備。具體操作步驟請見文檔（日誌數據離線歸檔到ODPS參考手冊、ODPS產品幫助文檔）。此處不再贅述。

導入成功後就可以在ODPS中查到性能數據，如圖：

使用R + ODPS進行性能分析

好的，終於可以開始正式進行性能分析啦。我們用的工具是專業的數據分析工具R語言。

首先載入數據：

注：rodps是ODPS內部基於R實現的SDK，還未通過阿裏雲服務對外開放。

一陣查詢之後，我們需要的原始數據已經準備在了data這個數據框裏麵。需要解釋一下的是qps這個字段計算的是不同的ip在查詢範圍內的任意一秒內處理好的請求數，我們約可以看作任意一秒內到達的請求數。

我們先將這個數據分成兩部分，一部分是0點到1點的數據，另一部分是1點到2點的數據。使用如下的命令放入data_ext_0和data_ext_1兩個數據框中：

請求的熱度

為了知道不同機器的請求的熱度，我們可以先做一下QPS的密度圖看下：

從圖上看，明顯能夠看出在不同時間段不同機器的請求熱度又明顯的不同，而且熱度相當不均勻，最熱的機器基本是最冷的機器的5-6倍左右。

圖上還可以基本看出，與0-1點的到達率相比，1-2點大部分機器的密度圖都有不同程度的右移，這意味著大部分機器的請求到達率有所提升。而0-1點到達率最高的一個機器（也就是xxx.xx.10.47），反而在1-2點的時候請求到達率有一定程度的下降。

讓我們來定量地分析一下數據，看看是否能夠支持上述結論。先是0-1點的數據，根據不同的機器IP統計出其均值(Mean)與標準差(SD)：

輸出（整理一下格式）：

然後是1-2點的數據：

輸出：

比較這兩組數據，能夠看到機器xxx.xx.10.10、xxx.xx.10.32、xxx.xx.10.36、xxx.xx.10.37、xxx.xx.10.42、xxx.xx.10.44、xxx.xx.10.46請求平均到達率有不同程度的提升，除了xxx.xx.10.47這台機器外，其餘機器的到達率的熱度有些微下降。xxx.xx.10.47這台機器的熱度下降明顯(從平均每秒到達386.26個請求降到了平均每秒到達265.73個請求)，但這台機器依然是熱度最高的機器。

定量的分析也能夠支持之前我們所觀察到的結論。這樣，我們就能把熱度的變化直觀、準確地描述出來。當然，我們可以繼續細化模型，從更多的維度觀察係統內正在發生的事情，得到更多更精確的結論。如Partition級的熱度統計，秒級的熱點遷移的變化等等。

以上所使用的數據分析工具僅限於作圖和統計均值、標準差。下麵我們仍然以這些數據為基礎，使用稍微高級一些的方法，得到一些更有意思的結論。

請求之間是否互相獨立

理論上，如果請求之間都是獨立的話，QPS的數值應該服從Poisson分布。那麼我們可以沿著這個思路，通過判斷各個機器在不同時間點上是否服從Poisson分布即可知道請求間的獨立性。

我們可以通過擬合Poisson分布，根據擬合的標準差判斷真實的數據與理論分布的差值。標準差越小，說明越服從Poisson分布，也就意味著這個XXServer收到的請求從時間上看越獨立。

擬合分布的原理較簡單，以Poisson為例：我們知道Poisson分布的概率質量函數是

其中隻有一個參數。而Poisson分布的均值(Mean)也為。於是我們可以以樣本的均值來作為擬合的Poisson理論分布的參數，那麼這個Poisson分布就被唯一確定了。之後我們需要計算樣本的抽樣點與理論分布的對應點的偏差，將他們加和之後再歸一化就是標準差了，作為樣本與理論模型間差異度的衡量指標。一圖勝千言：

標準差就是樣本數據（直方圖）與理論分布（紅線）的差值的絕對值的和與均值的比值。

實際中，不必手工將上麵的步驟都做一遍，R語言中MASS包的函數fitdistr就可以進行分布擬合。下麵我們用的就是這種方法。

我們先來看看0-1點的結果:

結果會是這樣的形式（截取一部分）：

整理一下結果的樣式：

我們可以看到最服從Poisson分布的機器是xxx.xx.10.45，標準差值有12.7%，已經相當不錯了。而偏差最大的則是機器xxx.xx.10.47，標準差已經達到了32.8%。注意到xxx.xx.10.47這台機器同時也是熱度最高的一台機器，那麼這個數據暗示我們有可能是我們的係統設計的不夠好，以致相同的一批請求連續訪問了某台機器，造成了熱點的不均衡。

好的，我們再看看1-2點的數據：

得到的結果整理如下：

這個數據與0-1點的數據做比較後，發現不同機器的請求時間獨立性各有增高或降低。尤其是xxx.xx.10.47這台重點機器，在熱度降低後，請求間獨立性加強了，可能意味著一些連續的訪問被調度到了其他的機器上。

從這個例子中，我們看到了不僅熱度是變化的，而不同XXServer上處理的請求的獨立性也是會轉移的。之前我們一直在關注請求的到達的特性，那麼下麵我們來看看用戶和係統設計者最關心的指標——係統的延時吧。

請求的延時與熱度的關係

由上麵的分析可知，在不同時間段內不同機器的熱度是不同的，那麼我們推測這些機器的平均請求延時也是不同的。所以我們下麵要進行的是一種時間序列分析。

我們先使用ODPS強大的數據處理能力按照分鍾粒度來準備數據，再整理一下時間表示，改為相對時間：

這樣就拿到了15台機器兩個小時內每分鍾的平均請求到達率(QPS)和平均請求延時數據。我們先看下這些機器在不同時間上的請求到達率的變化：

再看下這些機器在不同時間上的請求延時的變化：

是不是感到眼花繚亂？那我們先把xxx.xx.10.10的數據抽取出來，分析分析，然後再應用到別的機器上。先做個圖，看看QPS和Latency之間是否有聯係：

確實能夠看出QPS和延時之間是有一定的相關關係的，那麼我們就會進一步問：這兩者之間的關係是否能夠被定量地描述呢？

這個問題就需要我們更進一步的思考和分析了。我們注意到，似乎這兩者存在著線性關係。我們可以使用線性回歸的方法來驗證這一點。目前由於我們所收集的數據的維度較少，僅能夠推測QPS與延時的關係，這種隻有一個自變量和一個因變量的線性回歸方法叫做簡單線性回歸。

在R中，可以使用函數lm來進行線性回歸。為了展示方便，我們把延時的單位從us轉換為ms，進行回歸：

輸出的結果如下：

注意到線性回歸中QPS項是統計顯著的（p值<0.001），調整後的回歸係數是50%，表示樣本數據中有一半都可以被線性模型解釋。而QPS每增加1，平均請求的延時增加1.23 ms。

既然線性模型Work的不錯，那麼我們來看看這15台機器各自的QPS的影響和回歸係數吧：

得到的結果的格式如下：

整理一下這個結果，可以得到下麵的表格：

不幸地，除了第一台機器xxx.xx.10.10外，其他機器的回歸係數都不到10%，QPS的係數也非常低。這隻能說明簡單線性模型對其他機器的性能表現幾乎無法刻畫。雖然沒有得到預期的結論，但是我們可以得到一個相反的可能有些和直覺相悖的結論：XXServer端的請求平均延時與請求的熱度並沒有多大的簡單線性關係。

本節的分析說明了簡單線性模型難以刻畫係統的延時及其決定因素。既然延時對係統如此重要，是不是還有別的方法來深挖決定係統延時的因素呢？答案是肯定的，比如我們可以收集更多的數據，進行多元線性回歸； 或者可以假設不同自變量對因變量的影響不一定是一次的，而有可能是二次的、三次的，這樣的多項式回歸等。甚至使用各種非線性回歸方法以及其他的分析方法。

這裏大家可以多試試不同的模型和方法，一定會有不少收獲。

結語

SLS大大降低了分布式係統下的性能日誌的收集和查詢的成本，而ODPS強大的離線數據分析和處理能力則使大規模性能數據的處理成為了可能。這兩個工具為我們打開了一扇係統級的性能分析的大門。

在這些強大的計算能力的支持下，利用通用的數據分析方法和性能領域模型，不僅可以監控係統的性能表現、探尋性能問題產生的部位和原因，還能夠對係統的性能是否符合設計預期進行驗證、評估係統的設計與實現。進而提高我們的產品和服務的質量，最終獲得客戶的認可。當然，目前這項工作的狀態還比較初級，還有許多的工作要做。

希望本文能夠大家提供一個新的看待係統性能的方法，也請大家多多實踐，多多交流。祝玩得愉快！

P.S. 上文中一定有許多錯誤，還請各位大拿拍磚。

最後更新：2017-04-03 05:39:44

  上一篇： Cocos2d-x實例：設置背景音樂與音效-HelloWorld場景實現

  下一篇： maven詳解之坐標與依賴