《如何使用火焰圖來分析服務器負載》要點:
本文介紹了如何使用火焰圖來分析服務器負載,希望對您有用。如果有疑問,可以聯系我們。
LucidChart 提供在線編輯流程圖、網絡拓撲圖、ER 圖、 UML 圖以及腦圖等多種圖表服務,有超過 7 百萬的用戶,因其簡單直觀的交互體驗和強大的多人協作功能,是可以替代 Visio 的最佳選擇.
在 Lucid,我們使用面向服務的架構來建設我們的系統.其中字體服務(font service)就是其中之一,它負責根據字體族名稱和 unicode 編碼范圍來提供相應的字體服務,同時也對用戶上傳的字體進行校驗和檢查.在生產環境中,該服務的負載一直很高,這一點超出我們的預期(使用或等待 CPU 的平均線程數).特別從去年開始,我們注意到字體服務的負載高的驚人,特別是在晚上這樣的流量低峰時期.
幸運的是最終我們找到了根本原因,并通過改進大大提高了服務的整體性能和穩定性.通過下面的內容,您將了解到我們是如何做到的.
圖1: 字體服務在變更前后服務器平均負載對比
我們從 Netflix 找到了一個非常棒的火焰圖工具,并部署到生產環境. 此工具可以將多個不同調試分析工具的數據組合在一起并生成火焰圖,以可視化的方式展示服務器和 JVM 的資源使用情況.
如下圖所示,每個矩形表示一個棧幀,同時矩形的寬度代表了資源(比如 CPU 時間)的使用情況,Y 軸表示調用棧.通過識別那些寬的矩形塊,就能快速縮小問題范圍.在調試和排查字體服務時,它極大地幫助了我們.
圖2: 高負載時字體服務中一臺服務器的火焰圖
在高負載狀態下,我們對字體服務收集數據并生成了幾個火焰圖.下圖是其中之一,并且特別展示了 JVM 相關棧的部分.可以分析得出,大部分時間都花在了 libz.so
這一步(gzip 使用該庫進行壓縮/解壓縮操作),剩下大部分時間都花在了 XML 轉義和 UTF-8 編碼上.
圖3: JVM 相關?;顒拥木植炕鹧鎴D
首先多啰嗦幾句這個字體服務的一些背景情況.我們將所有字體相關數據存儲在 Amazon S3 中,具體來說是將每個字體的每個 unicode 范圍分別存為一個 S3 object
.當其他服務請求為了獲取字體族,一組 unicode 范圍,或者是用戶自定義字體時會向字體服務請求字體數據,接著字體服務將字體數據包裹在 XML 中返回.
功能非常簡單,并沒有什么明顯的密集型計算.但是對于出現的高負載問題,火焰圖幫助我們識別出了問題所在—— libz
,XML 轉義和 UTF-8編碼都使用了大量的 CPU.
但是為什么會產生這么多編碼和壓縮的消耗?記得前面提到晚上時間的負載反而是最高的嗎?我們的晚上(美國山區時間)正好是亞洲地區的白天,該地區很多用戶都使用中文、日文或韓文等亞洲語言.會進行大量的 gzip 解壓縮 → UTF-8解碼 → XML 轉義 → UTF-8編碼 → gzip 壓縮.相比于拉丁語系,單個 CJK 的 unicode 范圍比拉丁語系的 unicode 范圍大2個數量級(1MB:60KB).所以上述的轉換過程都壓到了 CPU 上,特別壓縮和解壓縮,以及 XML 轉義這類操作.
字體服務對請求的響應本質上只是 S3 上原始數據的集合.它確實需要執行一些重要的附加任務,如權限檢查和從字體族中檢索名稱.但是,字體服務根本沒必要擋在 S3 前面來代理那些字體數據!所以解決辦法很簡單, 直接用包含 S3 object 的鏈接(就是那些字體數據)的列表作為響應返回,字體服務不再從 S3 下載并重新編碼字體數據.所以從圖1中可以看出負載幾乎降低到可忽略的程度.
通過調試分析生產環境,我們能夠找到并消除那些不必要的任務和工作,進而降低服務器負載.
[1] Brendan D. Gregg的個人網站 http://www.brendangregg.com
[2] Flame graphs http://www.brendangregg.com/flamegraphs.html
[3] 白話火焰圖 https://huoding.com/2016/08/18/531
[4] Java Flame graphs http://www.brendangregg.com/blog/2014-06-12/java-flame-graphs.html
[5] OpenRestry 關于火焰圖在 Lua 中的使用?https://moonbingbing.gitbooks.io/openresty-best-practices/flame_graph.html
[6] 在 Netflix 中的應用 http://techblog.netflix.com/2015/07/java-in-flames.html
[7] 在 Netflix 中的應用 http://techblog.netflix.com/2016/04/saving-13-million-computational-minutes.html
原文來自微信公眾號:高可用架構