線上上 Kong 服務程序中實時統計 CPU 和記憶體用量最高的外掛(使用 OpenResty XRay)
要找出哪個 Kong 外掛最耗記憶體或 CPU,OpenResty XRay 會對執行中的 Kong 閘道器程序取樣,把資源用量按外掛逐個拆開——免重啟、免改程式碼、也無需特殊構建的 Kong。在下面這個案例中,bot-detection 外掛佔用了最多記憶體,而 prometheus 外掛消耗了最多 CPU。
Kong 是基於我們的開源 OpenResty 框架構建的一款流行的 API 閘道器軟體,它有靈活的外掛機制,既包括社群外掛,也包括您自己編寫的外掛。但這些外掛可能會導致 CPU 瓶頸、高記憶體使用或記憶體洩漏,而且往往很難判斷到底是哪一個在製造麻煩。OpenResty XRay 是一款動態追蹤產品,它能在線上程序上直接回答這個問題——高效且安全,就像對您的軟體進行 X 光檢查一樣。您只需將它指向 Kong 程序即可,不必安裝任何特殊外掛,也不必重新構建 Kong。
在這篇文章中,我們將向您展示如何使用 OpenResty XRay 來分析伺服器程序中 Kong 外掛的 CPU 和記憶體使用情況,並給出真實的結果示例,解釋它們的含義。
伺服器程序中所有 Kong 外掛的 CPU 使用情況
OpenResty XRay 可以對 Kong 程序進行一段時間的取樣,從幾秒到幾分鐘,這取決於該程序的繁忙程度。然後,它會向您展示 CPU 時間是如何在所有當前載入的外掛之間分配的。
例如,這是由 OpenResty XRay 為一個 Kong 程序生成的餅圖:
如您所見,在這種情況下,prometheus外掛佔用了大部分 CPU 時間,其次是ip-restriction外掛。其他外掛的 CPU 使用量可以忽略不計。這意味著,如果您想最佳化 Kong 伺服器的 CPU 效能,您應該關注這兩個外掛,看看是否可以改進或替換它們。
當然,這只是一個例子。在更復雜的 Kong 伺服器中,您可能會看到更多的外掛出現在這裡,並且分佈情況可能會根據流量和配置而有所不同。
Kong 外掛中的 CPU 使用情況
OpenResty XRay 也可以幫助您深入瞭解所有 Kong 外掛的詳細資訊,並檢視哪些 Lua 或 C 程式碼路徑消耗了更多的 CPU 時間。其中一個簡單的方法是檢視 Lua-land CPU 火焰圖,如下所示:
這張圖顯示了取樣期間在 CPU 上執行的 Lua 程式碼的呼叫棧。條形越寬,佔用的 CPU 時間就越多。您可以將滑鼠懸停在條形上以檢視更多資訊,例如函式名,檔名,行號,和 CPU 時間的百分比。
透過檢視這張圖,您可以快速發現您 Lua 程式碼中的熱點或效能問題,並相應地進行最佳化。您還可以比較不同的外掛或同一外掛的不同版本,看看它們在 CPU 使用方面有何不同。
當某個外掛不只是"重"、而是異常"燙手"時,同樣的火焰圖能揭示原因。舉一個實際案例:看我們如何把一次 Kong 的 CPU 瓶頸定位到自定義外掛裡隱藏的 Lua 異常,一路追到那個出問題的 string.lower 呼叫。
伺服器程序中所有 Kong 外掛的記憶體使用情況
同樣,OpenResty XRay 可以輕鬆地對 Kong 伺服器程序內的記憶體使用情況進行取樣。
下面是由 OpenResty XRay 為同一 Kong 程序生成的另一個餅狀圖:
可以看到,在這種情況下,bot-detection外掛佔用了大部分記憶體,prometheus外掛緊隨其後。其他外掛的記憶體使用量要低得多。這意味著如果您想減少 Kong 伺服器的記憶體佔用,您應該研究這兩個外掛,看看是否可以對它們進行最佳化或替換它們。
同樣,這只是一個例子。在不同的 Kong 伺服器中,您可能會看到不同的結果,這取決於配置的外掛和其他設定。
Kong 外掛中的記憶體使用情況
OpenResty XRay 也可以幫助您分析 Kong 外掛內 Lua GC 物件的記憶體使用情況。一種簡單的方法是檢視 GC 物件引用火焰圖,它顯示了記憶體在所有 GC 物件引用路徑上的使用分佈情況。
這張圖展示了在取樣期間佔用記憶體的 Lua GC 物件的引用路徑。條形越寬,所佔記憶體就越多。您可以將滑鼠懸停在某個條形上,檢視更多資訊,如物件型別、大小和記憶體百分比。
透過檢視這張圖,您可以快速發現您 Lua 程式碼中存在的記憶體洩漏或效率低下的問題,並相應地進行最佳化。您還可以比較不同的外掛或同一外掛的不同版本,看看它們在記憶體使用方面有何不同。
如果某個 Kong 外掛的記憶體隨時間持續攀升,同樣的 GC 物件引用火焰圖能把洩漏的引用路徑追到持有記憶體的物件——免重啟、免改程式碼。想進一步追到原始碼行,完整方法見我們的生產環境記憶體洩漏排查流程;也可以看一個真實案例:我們如何把一次 Lua GC 記憶體洩漏定位到被快取的 SSL 證書。
伺服器的額外負擔
您可能想知道使用 OpenResty XRay 是否會影響 Kong 伺服器的效能。答案是不會。當取樣時,新增到 Kong 伺服器程序的額外負擔通常非常小,可以忽略不計。而在不取樣的時候,程序執行速度則完全不受任何影響。
OpenResty XRay 的設計理念是非侵入性和輕量級。它不會干擾您的正常操作,也不需要對您的程式碼或配置進行任何更改。
常見問題
哪個 Kong 外掛最耗記憶體?
這取決於您的外掛和流量,因此唯一可靠的答案是實測您自己的閘道器。在本文采樣的這個程序中,bot-detection 外掛佔用了最多記憶體,prometheus 緊隨其後。OpenResty XRay 會在執行中的 Kong 程序上把記憶體按載入的外掛逐個拆開,讓您在自己的環境裡看到真正的"耗記憶體大戶"——無需特殊構建。
如何查出某個 Kong 外掛的記憶體洩漏?
OpenResty XRay 的 GC 物件引用火焰圖會顯示佔用記憶體的引用路徑,以及物件型別和大小。當某個外掛的記憶體持續攀升時,這張圖能定位到洩漏的引用路徑,免重啟、免改程式碼。完整方法(從 RSS 曲線一路追到原始碼行)見我們的生產環境記憶體洩漏排查流程。
哪個 Kong 外掛最耗 CPU?
同樣,實測勝過猜測。在取樣的這個程序中,prometheus 外掛佔用了最多 CPU 時間,其次是 ip-restriction。OpenResty XRay 會把取樣到的 CPU 時間分攤到所有載入的外掛上,其 Lua-land CPU 火焰圖還能深入到某個外掛內部的具體熱程式碼路徑。
用 OpenResty XRay 分析 Kong 外掛會帶來額外開銷嗎?
取樣時新增到 Kong 伺服器程序的額外開銷通常小到可以忽略;不取樣時,程序完全全速執行。OpenResty XRay 是非侵入式的:不需要改動您的 Kong 程式碼或配置,也不需要任何特殊外掛或構建選項。
下一步的計劃
我們並未止步於此。未來還有更多讓 OpenResty XRay 對您來說更加強大和有用的計劃。我們正在開發的一些功能包括:
- 顯示 Kong 不同外掛間的磁碟 I/O,網路 I/O 和其他資源指標的實時分佈情況。這將幫助您識別系統中的瓶頸或熱點,並相應地進行最佳化。
- 支援其他技術棧和開源軟體。我們希望使 OpenResty XRay 成為一種通用工具,可以分析任何線上應用程式,無論底層技術是甚麼。我們考慮的一些目標包括 Nginx 模組,Envoy 擴充套件,PostgreSQL 擴充套件,Perl/Python/Ruby 模組和庫,以及更多。
如果您有任何建議或對更多指標或功能的需求,請告訴我們。我們一直在傾聽您的反饋,並持續改進我們的產品以滿足您的需求。
結論
在本文中,我們向您展示瞭如何使用 OpenResty XRay 來分析伺服器程序中 Kong 外掛的 CPU 和記憶體使用情況。我們還向您展示了一些結果的示例,並解釋了它們的含義。
透過使用 OpenResty XRay,您可以輕鬆找出哪些外掛比其他外掛消耗更多資源,以及它們對整體效能有多大的影響。然後,您可以使用這些資訊來最佳化您的 Kong 伺服器,使其執行得更快更順暢。
如果您想更多地瞭解 OpenResty XRay 產品以及它能夠如何幫助您處理線上應用的其他方面的資訊,請訪問我們的網站或聯絡我們以瞭解更多細節。
關於作者
章亦春是開源 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. 公司的部落格網站 。也歡迎掃碼關注我們的微信公眾號:
翻譯
我們提供了英文版原文和中譯版(本文)。我們也歡迎讀者提供其他語言的翻譯版本,只要是全文翻譯不帶省略,我們都將會考慮採用,非常感謝!





















