隨著小紅書業(yè)務(wù)的快速發(fā)展，資源消耗和成本壓力顯著增加。在降本增效的大背景下，我們建設(shè)了性能持續(xù)優(yōu)化 & 追蹤平臺，來系統(tǒng)性輔助業(yè)務(wù)團隊解決性能問題，在業(yè)務(wù)系統(tǒng)日常的演化過程中，持續(xù)跟進、追蹤系統(tǒng)的性能退化并推動優(yōu)化。

目前，這一平臺已覆蓋小紅書搜索、推薦、廣告的 S0 服務(wù)，運行兩個多月以來，輔助業(yè)務(wù)團隊存量優(yōu)化超1萬 CPU 核；發(fā)現(xiàn)性能退化超1萬 CPU 核并跟進優(yōu)化。

1、背景

當(dāng)前，小紅書正處在快速發(fā)展期間，流量的快速上漲和業(yè)務(wù)的快速迭代，顯著增加了資源消耗和成本壓力。

在存量的資源占用上，我們要求研發(fā)人員對應(yīng)用做盡可能深度的性能優(yōu)化。然而，研發(fā)人員在對自己的模塊做性能優(yōu)化時，往往缺少工具來輔助分析，工具的合理選擇、環(huán)境配置、使用方式等各個方面，都有較高的學(xué)習(xí)成本。

另一方面，當(dāng)前性能優(yōu)化主要依靠個人經(jīng)驗進行逐個分析，缺乏通用化的機制，經(jīng)驗較難在團隊間共享。即使有人發(fā)現(xiàn)一個通用的性能問題，也很難衡量其涉及的模塊和整體的優(yōu)化空間。

此外，小紅書業(yè)務(wù)的日常迭代往往會帶來增量的資源消耗，即性能退化。特別是對于頻繁迭代的模塊，如一些推薦應(yīng)用，每天進行發(fā)版且每個版本涉及十多次不同的提交。在這些提交中，可能會隱藏著一些性能退化點。顯著的性能退化點會在性能壓測中被發(fā)現(xiàn)，而更多的性能退化往往是微小的，比如一個 commit 帶來了整體 CPU 1% 左右的占用，這樣微小的退化是隱蔽的，通過常規(guī)壓測等手段比較難以發(fā)現(xiàn)。

隨著業(yè)務(wù)的迭代，日積月累下，多個微小的性能退化會導(dǎo)致應(yīng)用整體性能的顯著惡化，進而積重難返。經(jīng)過一段時間的積累后，在排查這種問題時，面對動輒上百次的代碼提交歷史，開發(fā)同學(xué)很難排查出真正導(dǎo)致性能退化的提交是什么。最終只能以穩(wěn)定性的名義增加資源擴容，這樣的情況多次發(fā)生。

針對此，我們嘗試從整體上解決性能問題，設(shè)計開發(fā)了一套性能優(yōu)化和持續(xù)追蹤的平臺，來輔助應(yīng)用研發(fā)人員分析性能問題，同時在日常的業(yè)務(wù)系統(tǒng)演化過程中，持續(xù)跟進、追蹤系統(tǒng)的性能退化并推動優(yōu)化。

2、思路

我們的目標是從整體上解決性能問題。

問題主要聚焦在以下三個方面：

存量性能優(yōu)化：對應(yīng)用進行全方位的深入分析、診斷、優(yōu)化；優(yōu)化的經(jīng)驗積累后，橫向擴展，做到通用的優(yōu)化

增量性能退化攔截：業(yè)務(wù)迭代過程中，主動發(fā)現(xiàn)應(yīng)用的增量資源占用，即性能退化

性能穩(wěn)定性問題：對一些突發(fā)的性能惡化導(dǎo)致的穩(wěn)定性問題，快速定位原因

對應(yīng)的總體技術(shù)思路：

分析手段：基于 profiling 等采樣手段，來對應(yīng)用進行剖析

產(chǎn)品化：做到平臺化來提高易用性，研發(fā)人員可以盡可能低門檻、高效的使用；

持續(xù)優(yōu)化：在機制上做到持續(xù)優(yōu)化，將采樣分析做到常態(tài)化、例行化，將性能優(yōu)化、分析、防退化，融入到業(yè)務(wù)應(yīng)用的日常迭代中，關(guān)注應(yīng)用的每一個版本、每一次代碼提交、每一個策略實驗進行，持續(xù)追蹤業(yè)務(wù)應(yīng)用的性能表現(xiàn)。

3、整體方案 

我們的內(nèi)部落地整體架構(gòu)如下：

核心思路是通過對業(yè)務(wù)進程進行持續(xù)性的采樣、處理、存儲，并基于采樣數(shù)據(jù)做分析，來輔助性能優(yōu)化和發(fā)現(xiàn)性能退化。

數(shù)據(jù)采樣上，我們用單機低頻次持續(xù)采樣，降低成本，減少對應(yīng)用的影響。

在分析上，數(shù)據(jù)來自大數(shù)據(jù)存儲，并從縱向、橫向來對比分析：在縱向上，采用 merge + diff 分析，來發(fā)現(xiàn)退化點；在橫向上，提供跨應(yīng)用的通用查詢能力，查詢、分析函數(shù)粒度的資源占用。

3.1 數(shù)據(jù)采集、處理、存儲

3.1.1. 數(shù)據(jù)采集

當(dāng)前主要的數(shù)據(jù)采集方式是通過對進程進行 profiling，profiling 的原理是基于一定的頻率對運行進程進行采樣，來了解進程的特征。當(dāng)前，profiling 支持從多個方面對程序進行采樣分析，如 CPU、Memory、Thread、Lock、I/O 等。日常使用中，對 CPU 進行 profiling 的應(yīng)用最為廣泛。

一般的 CPU profiling 是 On-CPU，也就是 CPU 時間花費在哪些代碼執(zhí)行上。在 On-CPU 之外，還有 Off-CPU，指的是進程不在 CPU 上運行運行的時間，比如進程因為 IO、鎖等原因處于等待，花費了時間。所以，Off-CPU 是對 On-CPU 的補充，整體關(guān)系如下：

根據(jù)應(yīng)用的實際情況，綜合的對 On-CPU、Off-CPU 進行采樣，更為全面地了解程序的運行情況。

在多語言支持方面，當(dāng)前我們支持 C++、JAVA、Golang 等主流語言：

C++ 應(yīng)用：通過 Linux perf

JAVA 應(yīng)用：目前主流方案（如 IntelliJ IDEA 和阿里的 Arthas）是通過 Async-profiler 來實現(xiàn) profiling。Async-profiler 是將 Perf 的堆棧追蹤和 JDK 提供的 AsyncGetCallTrace 結(jié)合了起來，低開銷的支持多種 Perf event。我們的方案里也借助了這個工具，并針對我們的需求進一步做了定制開發(fā)

Golang 應(yīng)用：通過 Golang 內(nèi)置的 pprof

在采樣形式上，我們支持定時、主動和條件觸發(fā)三大形式。當(dāng)前，小紅書的線上應(yīng)用基本開啟了常態(tài)化、定時的 profiling

3.1.2 業(yè)務(wù)接入

采樣的 agent 以 daemonset 方式部署，支持對物理機上的多個業(yè)務(wù) pod 進行采樣。對應(yīng)用的采樣開啟、關(guān)閉是通過配置中心來下發(fā)。此外，支持更多的采樣配置，如：單次采樣的采樣頻率、采樣時間配置；多次采樣之間的采樣周期；采樣方式切換等。

因此，我們當(dāng)前做到了業(yè)務(wù)無感知接入，接入在分鐘級別生效。

3.1.3 存儲

在采樣結(jié)束后，對采樣后的數(shù)據(jù)進行解析、處理，如根據(jù)函數(shù)調(diào)用鏈統(tǒng)計 sample 數(shù)、過濾占比過低的函數(shù)調(diào)用鏈等。處理后，我們將數(shù)據(jù)進行存儲，用于后續(xù)的分析。我們的存儲方案選擇的是 clickhouse，在存儲 profiling 的數(shù)據(jù)之外，同時會把相關(guān)的環(huán)境變量信息一起存儲，如應(yīng)用名、應(yīng)用版本、機房等。此外，采樣后生成單 Pod 的火焰圖，將火焰圖壓縮并保存在對象存儲中，如騰訊云 cos。

3.1.4 資源消耗

在成本上，單次采樣的持續(xù)時間一般不超過一分鐘，多次采樣之間的周期間隔是小時級別，因此對應(yīng)用程序基本沒有影響；單次 pod 單次采樣，經(jīng)處理并保存到 clickhouse 的數(shù)據(jù)在千行的規(guī)模。所以整體的項目成本基本是存儲成本，即 clickhouse 和對象存儲，都很便宜，整體近乎零成本。

3.2 存量優(yōu)化

3.2.1 目標

根據(jù)我們的觀察和經(jīng)驗，一線研發(fā)同學(xué)對生產(chǎn)服務(wù)的診斷分析訴求長期是被壓制的，主要原因在：

· 公司出于安全需要，會對生產(chǎn)環(huán)境的網(wǎng)絡(luò)和權(quán)限進行管控。

這導(dǎo)致一些診斷會非常麻煩，例如，小紅書有一些系統(tǒng)采用了超大 Java Heap，如果要對此應(yīng)用做堆分析需要的步驟：

1. dump 堆到本機指定為止；
2. 傳輸 hprof 文件到指定跳板機；
3. 從跳板機下載 hprof 文件到本地；
4. 本地需要花數(shù)小時對 hprof 文件建索引，對于幾十 GB 的堆，本地往往由于機器性能不夠，最終可能還是無法完成分析；

· 通過一些診斷工具，我們可以觀測到很多系統(tǒng)運行指標，但對指標的解讀往往需要很多經(jīng)驗和對業(yè)務(wù)的理解。

如運行 free 命令，我們可以得到系統(tǒng)的內(nèi)存使用指標（free/buffer/cache）。然而這些指標到底意味著什么？對一個特定的應(yīng)用，當(dāng)前水位是否合理？這對使用者是有較高的基礎(chǔ)和業(yè)務(wù)背景知識要求。

由于這些限制和不便，使得我們一線資深研發(fā)同學(xué)日常對性能的關(guān)注逐漸變少，而一些新同學(xué)更是望而卻步。最終系統(tǒng)由于缺乏“體檢”，既不能治于未?。挥忠蛉狈ο到y(tǒng)的足夠認知，導(dǎo)致需要治療時又無從下手。

為此，我們設(shè)定了一個小目標：把診斷變成一個日常觸手可及的事：

· 開箱即用：

我們將一些常用的工具打包成一個工具箱，一鍵（或默認）安裝到目標容器里；

· 白屏化：

所有操作都在網(wǎng)頁上通過點擊拖拽完成，研發(fā)同學(xué)不需要記住很多命令參數(shù)，同時對工具的輸出做解析和解釋；

· 知識庫：

縱向上，我們會積累歷史指標供參考。橫向上，我們會總結(jié)一些共性的優(yōu)化點供研發(fā)同學(xué)參考。

3.2.2 工具

3.2.2.1 基礎(chǔ)信息展示

這部分主要展示一些進程和環(huán)境相關(guān)的基礎(chǔ)信息，OS、JVM、機器配置、啟動參數(shù)、環(huán)境變量等。方便用戶迅速了解一些應(yīng)用的基本信息。

3.2.2.2 運行時指標

這塊主要涵蓋一些秒級運行時的 Metrics（如 CPU 利用率，GC 信息），loaded class，線程池狀態(tài)等。這塊作為大盤指標的補充，在 agent 測內(nèi)嵌了一個小型的時序數(shù)據(jù)庫，直接在端上存儲幾個重要的秒級指標。幫助用戶捕捉一些更細粒度的信號。

3.2.2.3 采樣&分析

目前我們主要提供了針對 Java 的一些在線分析能力。對于 Java 程序，目前使用頻率最高的是堆分析，用戶可以在平臺上一鍵觸發(fā) Heap dump，dump 文件生成后會自動上傳到內(nèi)部部署的 apache-jifa worker 上，用戶可以在列表里面找到對應(yīng)的入口，跳轉(zhuǎn)到 jifa 頁面去做詳細的堆分析。

同時，基于 profiling 工具，如 async-profler，用戶可以一鍵生成 cpu、alloc 及 lock 的火焰圖，并在線展示。通過這些火焰圖，能很方便找到系統(tǒng)的一些熱點，從而有針對性的去優(yōu)化。

3.2.3 通用優(yōu)化機制

在存量優(yōu)化方面，我們的一個創(chuàng)新點就是通用優(yōu)化機制。在對各應(yīng)用進行常態(tài)化的 profiling 后，我們有了所有應(yīng)用的性能原始數(shù)據(jù)，進一步的想法就是大數(shù)據(jù)檢索：經(jīng)過眾多的性能優(yōu)化 case 后，將常見的基礎(chǔ)庫和已知的通用性能問題抽象成規(guī)則庫，從而可以匹配其在線上所有模塊的消耗占比和整體占用核數(shù)，來發(fā)現(xiàn)更多優(yōu)化空間，達到批量優(yōu)化并且追蹤優(yōu)化的效果。

下圖所示，為線上一個基礎(chǔ)庫 SDK 在各個應(yīng)用中的資源消耗情況，分別統(tǒng)計了 CPU 占比和對應(yīng)的核數(shù)。在此基礎(chǔ)上，批量的推動應(yīng)用進行優(yōu)化。

3.3 性能持續(xù)優(yōu)化

3.3.1 總體思路

針對業(yè)務(wù)迭代過程中發(fā)生的性能退化，持續(xù)跟進、追蹤。

總體的思路是：首先是發(fā)現(xiàn)性能退化點，精確到函數(shù)級別；并進一步關(guān)聯(lián)、發(fā)現(xiàn)對應(yīng)的變更事件(代碼提交、算法實驗等)；后續(xù)跟進整個性能退化的生命周期，推動優(yōu)化，直到最終解決性能退化。

3.3.2 發(fā)現(xiàn)

3.3.2.1 機制

首先是自動化巡檢，即每天會定期檢查接入的服務(wù)是否存在潛在性能退化，通過昨天和前天晚高峰性能數(shù)據(jù)，檢查各應(yīng)用是否有性能退化情況，并推送到相關(guān)企微群。

此外，通過接入 QA 流水線、上線平臺等方式，在上線前、上線后回調(diào)，更早期攔截性能退化。

3.3.2.2 發(fā)現(xiàn)方式

通過性能數(shù)據(jù) merge + diff 分析：根據(jù)查詢條件，在將新版本和基準版本分別進行數(shù)據(jù)聚合后，進行對比；通過分析對比后的 diff，發(fā)現(xiàn)異常變化點并判斷是否有性能退（精確到函數(shù)）。當(dāng)前支持機房、版本和時間區(qū)間等多種條件。

此外，為了衡量性能退化點的影響，將退化的程度與對應(yīng)占用的 CPU 核數(shù)相關(guān)聯(lián)，也可以讓研發(fā)人員們了解對應(yīng)退化點對于系統(tǒng)整體性能的影響，有更直觀的感受。

3.3.2.3. 退化點展示

火焰圖是一種比較理想的展示函數(shù)調(diào)用關(guān)系的形式，同時也可以方便的定位其在整體中的位置。因此，我們通過定制化的差分火焰圖，展示退化點對應(yīng)的詳細函數(shù)棧情況，并用顏色來標記、突出性能退化點，用不同的顏色來區(qū)分退化的程度；同時在火焰圖上展示對應(yīng)的 CPU 核數(shù)，來強化退化程度，增加火焰圖的表達內(nèi)容。

此外，為了支持版本間消失的代碼邏輯，使用了消失火焰圖。這樣，組合起來，可以展示兩個版本之間函數(shù)棧的新增、修改、消失等場景。

在技術(shù)實現(xiàn)上，我們在開源的 flamescope（https://github.com/Netflix/flamescope）基礎(chǔ)上定制開發(fā)，進行實時進行處理和渲染，根據(jù)需求可以靈活的支持各種應(yīng)用場景。所有的火焰圖和 diff 計算均從 clickhouse 中讀取數(shù)據(jù)處理。

線上的一個實際性能退化例子如下，其中差分火焰圖中展示了退化點對應(yīng)的函數(shù)調(diào)用、退化對應(yīng)的 CPU 核數(shù)；消失火焰圖展示了版本之間消失的代碼邏輯。

3.3.3 定位變更

在確定性能退化后，根據(jù)性能退化的情況（如退化的時間點、函數(shù)棧），檢索應(yīng)用對應(yīng)的變更事件，如算法實驗變更、配置中心下發(fā)變更、上線記錄等。未來，會進一步嘗試根據(jù)函數(shù)棧來管理 git 的提交情況，關(guān)聯(lián)可能代碼提交。

3.3.4 持續(xù)追蹤

為了方便追蹤性能退化問題的進度，我們會把核實過的信息推送至內(nèi)部風(fēng)險平臺來錄入留痕，并且通過趨勢圖追蹤優(yōu)化情況。

如上圖所示，這是一個線上應(yīng)用性能退化的實際 case，通過函數(shù)調(diào)用鏈的 CPU 使用率趨勢圖可以看出性能退化發(fā)生的起始點，同時可以看出該性能退化是否得到了修復(fù)、何時修復(fù)，這樣可以清晰的看到性能退化問題的過程，方便持續(xù)追蹤性能問題。

3.4 性能異常問題定位

在采樣的方式上，支持條件觸發(fā)方式，即配置描述異常態(tài)的觸發(fā)條件(比如 CPU 突漲等)，當(dāng)滿足條件時進行數(shù)據(jù)的采集和上報。再基于上述的 merge + diff 數(shù)據(jù)分析方法，將異常態(tài)和正常態(tài)的數(shù)據(jù)分別進行匯聚后，做對比分析，通過 diff 分析來定位出導(dǎo)致突漲的根因，同時關(guān)聯(lián)對應(yīng)的變更。

4、展望

未來，我們希望能夠去探索更多的性能優(yōu)化手段，如 PGO；以及基于 PMU 指標，探索“內(nèi)存大頁”等技術(shù)落地；同時，我們也希望能夠收集更多的性能指標，如 walltime、cpu cache、mem bindwith 等，來覆蓋更多的性能分析場景。

5、作者簡介

韓柏：技術(shù)部/可觀測技術(shù)組

小紅書可觀測技術(shù)工程師，畢業(yè)于上海交通大學(xué)，從事推薦架構(gòu)、基礎(chǔ)架構(gòu)工作，在可觀測、云原生、中間件、性能優(yōu)化等方面有較為豐富的經(jīng)驗。

小粟：技術(shù)部/可觀測技術(shù)組

小紅書可觀測技術(shù)工程師，畢業(yè)于西安交通大學(xué)，先后在推薦架構(gòu)、云原生、可觀測領(lǐng)域從事相關(guān)工作，現(xiàn)專注于通用日志體系的建設(shè)。

蘇星河：技術(shù)部/可觀測技術(shù)組

小紅書可觀測技術(shù)工程師，畢業(yè)于南京大學(xué)計算機系，之前在小紅書供應(yīng)鏈管理、大數(shù)據(jù)、推薦等諸多業(yè)務(wù)積累了豐富的經(jīng)驗，最近在專注JVM在線診斷及性能優(yōu)化相關(guān)的工作。