在某些關鍵時刻，核心服務的穩定性直接關係到業務的成敗。最近，我們的一位客戶就遇到了讓運維團隊頭疼的問題：Nginx 服務的記憶體像“黑洞”一樣不斷膨脹。臨時重啟只能緩解一時壓力，問題卻總是死灰復燃。我們將透過這篇文章分享如何用 OpenResty XRay 快速發現並定位這一隱蔽的記憶體洩漏問題，以及如何把複雜、漫長的記憶體洩漏定位過程，賦能成一個“診斷 → 規劃 → 驗證”可複用的閉環。

技術困境與初步診斷

我們一位客戶的核心 Nginx 服務記憶體佔用持續上漲，彷彿一個“記憶體黑洞”。雖然臨時重啟能緩解一時的壓力，但問題很快再次出現。

挑戰與風險：

• 技術層： 生產環境下的 C/C++ 程序的記憶體洩漏，堪稱最難解決的問題之一。傳統除錯工具（如 GDB）無法直接用於線上，而程式碼審計則如同大海撈針，耗時且低效。
• 業務層： 如果放任不管，記憶體消耗會持續加劇，導致 響應變慢、頻繁崩潰，最終威脅核心業務的連續性。這意味著：使用者體驗下降，使用者逐漸流失；品牌聲譽受損和直接的經濟損失。

靠定時重啟來“續命”，無異於飲鴆止渴，讓整個業務長期暴露在風險之中。在接到求助後，我們立即利用動態追蹤產品 OpenResty XRay 直接在生產環境對記憶體分配進行分析。僅僅幾分鐘，工具就自動生成了記憶體洩露火焰圖，為問題排查提供了清晰的突破口。

火焰圖一目瞭然地顯示了記憶體分配主要集中在三個區域：

1. Nginx 記憶體池
2. TLS 相關記憶體
3. ngx_dubbo_module 函式

Nginx 記憶體池和 TLS 都是久經考驗的成熟元件，發生記憶體洩漏的機率極低。因此，我們將分析的重點迅速鎖定在嫌疑最大的 ngx_dubbo_module 函式上。

火焰圖指路，鎖定記憶體洩漏的“重災區”

第一步：鎖定可疑函式。

藉助 OpenResty XRay 的強大動態追蹤能力，我們不需要翻閱海量日誌或進行地毯式程式碼審計，就能像“庖丁解牛”一樣高效地剖析問題，我們 zoom in 嫌疑最大的 ngx_dubbo_module 函式。

記憶體洩露火焰圖清晰地指出，記憶體分配的峰頂指向了 ngx_dubbo_hessian2_encode_payload_map 函式，這裡就是記憶體洩漏的“重災區”。

第二步：深入程式碼，發現疑點。

透過火焰圖，我們直接定位到了那個最可疑的函式。深入其原始碼，我們很快就發現了問題所在：程式碼在處理資料時，會專門為一部分內容分配一塊新的記憶體來存放。

然而，通讀整個處理流程，我們都沒有找到任何釋放這塊記憶體的操作。直覺告訴我們，問題就出在這裡。這塊新分配的記憶體被封裝後，傳遞給了後續的模組進行處理。它的生命週期到底由誰管理？

第三步：順藤摸瓜，水落石出。

為了弄清真相，我們追溯了這塊記憶體在後續模組中的傳遞路徑。我們發現，接收這塊記憶體的模組擁有一套自己的記憶體回收機制，用於自動清理不再使用的物件。

關鍵在於，一個物件是否會被這個機制回收，取決於它是如何被“告知”給這個模組的。在客戶的場景中，這塊記憶體被傳遞進去時，由於其建立方式的特殊性，它被錯誤地標記為“無需本模組管理”。這相當於告訴回收機制：“這塊記憶體有別人管，你不用操心。”然而，實際上並沒有任何“別人”來負責釋放它。

由於這個錯誤的訊號，自動回收機制完美地跳過了這塊記憶體。隨著請求不斷湧入，無數這樣的記憶體被分配出來，卻永遠得不到釋放，記憶體洩漏由此產生。我們透過火焰圖直接定位到了分配記憶體的函式的具體程式碼行，並清晰地指出了這塊記憶體為何沒能被自動回收。客戶根據這一明確的線索，透過分析相關原始碼，很快就確認了記憶體洩漏的根本原因。

從被動應對到主動賦能：XRay 帶來的排障新閉環

在追求系統穩定性的道路上，許多團隊陷入了一個怪圈：為了解決問題，蒐集更多的資料來獲得更多的線索，為了收集更多的資料，增加更多的監控指標，搭建更復雜的 Dashboard，投入鉅額預算購買更多的監控工具。結果這些工具帶來了大量碎片化的資訊，資料越來越多，訊雜比卻越來越低。工程師們依然要在“資料墳場”中翻找蛛絲馬跡，淘金一樣篩選有價值的資訊。

這種模式的根本缺陷在於，它將技術問題如記憶體洩漏與商業成本：

• 一次記憶體洩漏告警，看似只是技術指標的波動，背後卻是工程師寶貴時間的流失；
• 一次頻繁的線上異常，不僅威脅系統穩定，更意味著業務中斷的潛在風險；
• 持續高昂的監控投入，卻換不來相匹配的洞察產出。

說到底，這不是“資料太少”，而是“有用的答案太少”。真正高效的可觀測性工具，應該像一把“手術刀”，直接切入問題根源，而不是再給團隊一把“鐵鍬”，讓大家在資料堆裡沒日沒夜地挖。這正是下一代可觀測性平臺所要解決的核心矛盾：

• 從表象指標走向因果鏈條
• 從被動告警走向主動分析洞察
• 從消耗人力走向真正釋放研發生產力

總結

在這個案例中，OpenResty XRay 展示了另一種方式：把複雜、漫長的過程，變成一個可複用的閉環。我們稱之為 “診斷 → 規劃 → 驗證”。

• 精準切入: 傳統方法是“多看點資料，也許能找到線索”。XRay 的方式則不同：透過火焰圖等視覺化工具，它直接指向問題所在，讓團隊在幾分鐘內就能看到根因。它提供的不是更多的監控指標，而是關鍵的、能推動行動的洞察。
• 從確鑿證據出發制定方案: 當知道問題精確落在某一行程式碼或某個 C/C++ 程序時，修復方案就能直奔主題。團隊不需要反覆試錯，而是基於明確證據，快速形成清晰、有效的行動步驟。
• 立即驗證，形成完整閉環: 修復上線後，XRay 可以再次分析，確認問題是否已徹底消除。這種快速驗證機制，讓整個過程真正閉環：診斷、行動、驗證，環環相扣。

這種閉環能力帶來的價值，已經遠遠超越了單一 Bug 的解決：

• 技術價值： 賦能團隊以無侵入的方式，直達生產環境中的 C/C++ 程序，將複雜問題簡單化、視覺化。
• 商業價值：
  • 保障業務穩定： 快速消除潛在故障，保障服務的高可用性。
  • 提升研發效率： 將工程師從繁瑣、低效的 Debugging 中解放出來，投入到更有價值的業務創新中。
  • 最佳化資源成本： 避免因未知效能問題而進行的過度資源配置，實現真正的成本控制。

在這個資料過載的時代，技術團隊需要的不再是更多監控面板，而是一種更智慧、更可信賴的方式，幫他們在最短時間內找到問題、解決問題，這才是可觀測性的真正價值所在。

關於 OpenResty XRay

OpenResty XRay 是一款動態追蹤產品，它可以自動分析執行中的應用，以解決效能問題、行為問題和安全漏洞，並提供可行的建議。在底層實現上，OpenResty XRay 由我們的 Y 語言驅動，可以在不同環境下支援多種不同的執行時，如 Stap+、eBPF+、GDB 和 ODB。

關於作者

章亦春是開源 OpenResty^® 專案創始人兼 OpenResty Inc. 公司 CEO 和創始人。

章亦春（Github ID: agentzh），生於中國江蘇，現定居美國灣區。他是中國早期開源技術和文化的倡導者和領軍人物，曾供職於多家國際知名的高科技企業，如 Cloudflare、雅虎、阿里巴巴, 是 “邊緣計算“、”動態追蹤 “和 “機器程式設計 “的先驅，擁有超過 22 年的程式設計及 16 年的開源經驗。作為擁有超過 4000 萬全球域名使用者的開源專案的領導者。他基於其 OpenResty^® 開源專案打造的高科技企業 OpenResty Inc. 位於美國矽谷中心。其主打的兩個產品 OpenResty XRay（利用動態追蹤技術的非侵入式的故障剖析和排除工具）和 OpenResty Edge（最適合微服務和分散式流量的全能型閘道器軟體），廣受全球眾多上市及大型企業青睞。在 OpenResty 以外，章亦春為多個開源專案貢獻了累計超過百萬行程式碼，其中包括，Linux 核心、Nginx、LuaJIT、GDB、SystemTap、LLVM、Perl 等，並編寫過 60 多個開源軟體庫。

關注我們

如果您喜歡本文，歡迎關注我們 OpenResty Inc. 公司的部落格網站 。也歡迎掃碼關注我們的微信公眾號：

翻譯

我們提供了英文版原文和中譯版（本文）。我們也歡迎讀者提供其他語言的翻譯版本，只要是全文翻譯不帶省略，我們都將會考慮採用，非常感謝！