← 返回

記憶體不再偽洩漏：LuaJIT-plus 如何最佳化記憶體碎片化並解決 RSS 虛高

章亦春釋出於 Nov 28, 2025 更新於 Nov 28, 2025

預計閱讀 8 分鐘

閱讀次數

在維護大規模、高併發的 OpenResty/LuaJIT 服務時，一個普遍存在的棘手問題是程序常駐記憶體（RSS）的持續增長，而 Lua GC 層面卻顯示記憶體佔用很低。這種看似“洩漏”卻非洩漏的現象，常導致容器因 OOM（Out of Memory）被終止，嚴重影響線上服務的穩定性。要解決這一頑疾，光靠調整引數往往隔靴搔癢，我們需要更底層的視角和手段。

lj-resty-memory 正是我們為此打造的深度記憶體剖析工具，它能直觀揭示 RSS 與 GC 佔用之間的巨大鴻溝，而 LuaJIT-plus 則是我們提供的最終解法：一個具備主動記憶體歸還能力的增強版執行時，旨在從根源上剷除記憶體碎片化帶來的 RSS 虛高問題。本文將結合線上真實案例，首先使用 lj-resty-memory 精準定位問題，然後闡述 LuaJIT-plus 是如何透過其智慧記憶體管理機制，將不可控的記憶體增長變為健康、可預測的模式。

使用 OpenResty XRay 快速透視和解決您的軟體問題

深度解析：為何 Lua 釋放了記憶體，作業系統卻收不到？

記憶體自治：與 glibc 的“分道揚鑣”

要理解 RSS 為何居高不下，首先要明確 LuaJIT 獨特的記憶體治理策略。LuaJIT 並沒有依賴 glibc 的 malloc/free，而是構建了一套專用的記憶體分配器。

通用分配器（如 glibc 的 malloc）為滿足多樣化的應用場景，其設計必然是妥協與平衡的結果。然而，對於 LuaJIT 這種追求極致效能的 JIT 執行時環境，尤其是在多執行緒高併發模型下，直接使用 glibc 會因其鎖競爭 (Lock Contention) 機制而成為嚴重的效能瓶頸。

在多執行緒高併發模型下，當大量執行緒同時向 glibc 請求分配或釋放記憶體時，它們必須競爭同一個全域性鎖或數量有限的 Arena 鎖。這種激烈的競爭會導致記憶體操作被強制序列化，使得多核處理器的並行優勢無法發揮，鎖本身成為了限制系統吞吐量和擴充套件性的關鍵瓶頸。

為了從根本上解決這一問題，LuaJIT 實現了一套專為 GC 物件（如 Tables, Strings, Closures, Userdata）最佳化的內部分配器。它透過 mmap 等方式一次性向作業系統批發大塊記憶體頁，然後在使用者態內部進行精細化的管理和零售。

這種設計的核心優勢在於完全繞開了 glibc 的鎖競爭機制。由於記憶體管理在 LuaJIT 內部閉環完成，不同的執行執行緒（或 Lua State）可以獨立、高效地進行記憶體分配，無需等待任何全域性鎖，從而確保了在高併發環境下的極致效能。

然而，這也導致 LuaJIT 的 GC 記憶體形成了一個與系統分配器隔絕的“記憶體孤島”。因此，任何旨在緩解 glibc 鎖競爭的調優嘗試（例如調整 MALLOC_ARENA_MAX 環境變數），對 LuaJIT 內部 GC 物件的記憶體行為是完全無效的，因為這些物件的分配根本不經過 glibc 的鎖控流程。

核心癥結：“貪婪”的持有策略

既然內部分配器為效能而生，為何會導致 RSS 膨脹？答案在於其記憶體回收策略。

在週期性任務、流量洪峰或長連線等業務場景下，應用會瞬時建立海量 Lua 物件，任務結束後，這些物件被 GC 回收。GC 將這些記憶體標記為“空閒”，但“空閒”不等於“歸還給作業系統”。我們可以透過一個停車場模型來具象化這一過程：

記憶體分配：大量車輛（Lua 物件）駛入一個巨大的停車場（由 mmap 申請的大塊記憶體）。
GC 回收：大部分車輛駛離，留下了大量成片的空閒車位（大塊記憶體被 GC 標記為 free）。
記憶體持有：儘管停車場裡已經有大片連續的空地，但只要這片巨大的停車場區域中還零星停著幾輛車（少量存活的 Lua 物件），停車場管理員（LuaJIT 分配器）就不會將任何空閒的土地（Memory Page）“退租”給地主（作業系統）。

這就是 LuaJIT 分配器“貪婪”策略的核心：為了最佳化效能，它傾向於持有並快取已釋放的記憶體塊，以備下次分配時複用，從而避免昂貴的系統呼叫。然而，這種策略意味著，即使總空閒記憶體佔比極高，並且存在大塊連續的空閒記憶體，分配器也不會主動透過 munmap 將它們歸還給 OS。

這種策略在長連線或流量突發場景下會引發嚴重的副作用：

虛高的 RSS： 實體記憶體被大量利用率極低的“碎片頁”佔用，導致監控指標常年報警。
偽記憶體洩漏： 儘管 LuaJIT 報告 collectgarbage("count") 很低，但系統層面記憶體佔用卻很高，極易誤導排查方向。
OOM 隱患： 當新的大物件請求到來時，由於現有記憶體池高度碎片化，無法提供連續空間，分配器被迫再次向 OS 申請新頁。舊的還著不走，新的又不斷進來，最終可能導致容器被 OOM Killer 誤殺。

使用 lj-resty-memory 量化記憶體空洞

理論分析需與資料驗證相結合。我們使用 lj-resty-memory 工具對一個典型的“高 RSS、低 GC 佔用”的線上程序進行剖析，以量化問題。

應用層記憶體使用分解

首先，對程序整體記憶體佔用（512.06MB）進行分解：

資料顯示，71.2% 的記憶體由 LuaJIT 的內部分配器管理，這明確了問題的主要歸因。

HTTP LuaJIT 子系統記憶體透視

接下來，我們深入分析這 71.2% 的記憶體構成：

這是定位問題的關鍵證據。 在 LuaJIT 持有的超過 515MB 記憶體中，僅有 5.9% 被活躍的 GC 物件佔用，而高達 94.1% 是已回收但未歸還給作業系統的空閒記憶體。這精確地印證了我們的判斷：週期性任務結束後，GC 已完成其工作，但留下的記憶體池因碎片化而無法被有效釋放，形成了巨大的記憶體“空洞”。

透過 LuaJIT-plus 實現主動記憶體歸還

正如前文分析，問題的根源在於 LuaJIT 內部分配器的設計特性，而非應用程式碼本身。為了徹底解決這一難題，我們開發了 LuaJIT-plus，一個經過生產環境嚴苛考驗的增強版 LuaJIT 執行時。它並非簡單的引數調整或程式碼技巧，而是從記憶體分配和回收機制的根源入手，賦予執行時更智慧的記憶體治理能力。

面對這種由架構特性引發的問題，傳統的應用層程式碼最佳化（如物件複用、減少 table 建立）雖然有益，但往往收效甚微，因為它無法解決根本的記憶體頁歸還問題。根本性的解決方案需要從執行時層面入手。LuaJIT-plus 針對此痛點，引入了更智慧的記憶體治理策略，其核心是打破分配器“被動持有”的僵局：

積極的空閒塊管理： 增強對記憶體池中空閒塊的識別與合併能力，為大塊記憶體的歸還創造條件。
基於啟發式演算法的主動歸還 (Smart Release): 當檢測到大塊連續記憶體長時間處於空閒狀態時，主動呼叫 madvise(ptr, len, MADV_DONTNEED) 系統呼叫。

madvise 的作用是向作業系統核心提供建議，告知其“這片地址空間的實體記憶體我暫時不再需要，你可以回收”。核心在收到此建議後，會將對應的物理頁釋放，從而直接降低程序的 RSS。當未來再次訪問這片地址時，會觸發缺頁中斷，由核心重新分配物理頁。這對效能的影響極小，但對降低實體記憶體佔用效果顯著。

生產環境實測效果： 在一個客戶的監控系統中，其業務負載呈典型的週期性“鋸齒狀”，導致 LuaJIT 程序 RSS 階梯式上漲且從不回落，頻繁觸發 OOM 告警。

最佳化前： RSS 曲線只增不降，記憶體使用模型不可預測。
切換至 LuaJIT-plus 後： RSS 曲線呈現健康的“呼吸”形態。負載高峰期記憶體合理增長，任務結束後 RSS 迅速回落至基線水平，將實體記憶體資源釋放給系統中的其他程序。

該方案不僅根除了 OOM 風險，更重要的是，它使系統的記憶體使用行為變得高度可預測，這對於保障大規模服務的穩定性至關重要。

核心洞察與工程實踐建議

作為負責系統穩定性和效能的負責人，我們必須超越業務程式碼，深入理解底層執行時的行為。

對於正在使用或評估 OpenResty/LuaJIT 技術棧的團隊，以下是我們的核心建議：

升級觀測維度： 監控體系必須能夠區分 GC 邏輯記憶體 (collectgarbage("count")) 和 程序實體記憶體 RSS。當兩者出現巨大且持續的偏差時，應判定為碎片化問題，而非傳統意義上的洩漏。
明確問題域： 停止在 glibc 引數上浪費時間。LuaJIT 的 GC 記憶體問題需要從其內部分配器層面尋找解決方案。
擁抱系統級方案： 當外部碎片化成為瓶頸時，應用層最佳化的邊際效益會銳減。引入像 LuaJIT-plus 這樣具備主動記憶體歸還能力的增強版執行時，是從根本上解決 RSS 虛高問題的最有效、最徹底的工程化路徑。

LuaJIT-plus 是我們團隊基於多年大規模 OpenResty 服務維護經驗，精心打造的企業級 LuaJIT 執行時。它不僅解決了本文深入剖析的記憶體碎片化問題，還包含了一系列效能最佳化與穩定性增強特性，旨在為您的關鍵業務提供堅實可靠的底層支援。如果您正面臨類似的挑戰，或希望進一步提升系統的效能與可預測性，歡迎瞭解和試用 LuaJIT-plus，讓專業的工具助您一臂之力。

立即申請 OpenResty XRay 試用

關於 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 多個開源軟體庫。