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

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

1、背景

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

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

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

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

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

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

2、思路

我們的目標(biāo)是從整體上解決性能問題。

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

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

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

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

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

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

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

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

3、整體方案 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1.3 存儲

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

3.1.4 資源消耗

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

3.2 存量優(yōu)化

3.2.1 目標(biāo)

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

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

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

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

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

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

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

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

· 開箱即用：

我們將一些常用的工具打包成一個工具箱，一鍵（或默認(rèn)）安裝到目標(biāo)容器里；

· 白屏化：

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

· 知識庫：

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

3.2.2 工具

3.2.2.1 基礎(chǔ)信息展示

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

3.2.2.2 運(yùn)行時(shí)指標(biāo)

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

3.2.2.3 采樣&分析

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

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

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

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

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

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

3.3.1 總體思路

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

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

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

3.3.2.1 機(jī)制

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

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

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

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

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

3.3.2.3. 退化點(diǎn)展示

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

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

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

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

3.3.3 定位變更

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

3.3.4 持續(xù)追蹤

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

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

3.4 性能異常問題定位

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

4、展望

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

5、作者簡介

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

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

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

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

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

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