← 返回

Nginx Worker CPU 佔用不均：定位未啟用 reuseport 與 cjson 解析瓶頸

章亦春釋出於 Jul 2, 2025 更新於 Aug 12, 2026

預計閱讀 5 分鐘

閱讀次數

Nginx worker 程序 CPU 佔用不均——個別 worker 打滿、其餘接近空閒——往往是請求分配層面的問題，比如監聽埠未啟用 reuseport 選項。在這個真實客戶案例中，OpenResty XRay 把一套 DNS 服務的 CPU 不均衡精確定位到了這一配置缺失，外加一個消耗 60% CPU 時間的 cjson_decode 熱點，並在幾分鐘內將核心瓶頸的 CPU 消耗降低了 60% 以上。

下面按火焰圖逐步展開整個定位過程。

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

症狀：部分 Nginx Worker 程序 CPU 打滿，其餘接近空閒

客戶執行的 DNS 服務系統面臨嚴重的 CPU 使用率不均衡問題，部分 Nginx worker 程序 CPU 佔用率過高，而其他程序相對空閒。同時，系統整體響應延遲增加，特別是在高負載情況下表現更為明顯。這種不均衡不僅影響了服務的穩定性，還導致資源利用效率低下，增加了運營成本。

傳統的效能分析方法難以精確定位根本原因，因為問題涉及多個層面的複雜互動。在這種情況下，客戶請求 OpenResty XRay 團隊支援，我們立即使用 OpenResty XRay 對系統進行了全方位的效能剖析。

OpenResty XRay 如何定位根因

透過 OpenResty XRay 分析器，我們對目標系統進行了深入分析，發現了以下關鍵問題：

未啟用 `reuseport`：請求分配為何不均

首先，我們檢查了 Nginx 的配置狀態：

use_accept_mutex: 0
listening on: 0.0.0.0:8090, reuseport: 0
listening on: 0.0.0.0:3581, reuseport: 0
listening on: 0.0.0.0:8081, reuseport: 0
listening on: 0.0.0.0:8088, reuseport: 0
listening on: 0.0.0.0:11080, reuseport: 0
listening on: 0.0.0.0:8080, reuseport: 0
listening on: 0.0.0.0:9000, reuseport: 0
listening on: 0.0.0.0:9090, reuseport: 0
listening on: 0.0.0.0:1935, reuseport: 0
listening on: 0.0.0.0:80, reuseport: 0

發現所有監聽埠都未啟用 reuseport 選項，導致請求分配不均。

火焰圖顯示 `cjson_decode` 消耗了 60% 的 CPU 時間

透過 C 火焰圖分析，我們發現約 60% 的 CPU 時間消耗在 cjson 模組上。

從 Lua 火焰圖看，約 60% 時間消耗在 cjson_decode 操作，約 30% 時間消耗在 shcache.lua:load，僅約 5% 時間消耗在核心業務邏輯 dns_server.lua 中。

這表明 JSON 解析成為了絕對的效能瓶頸——與我們在這個 JSON 解析記憶體案例中診斷過的屬於同一類問題。

舊版 LuaJIT 帶來的 Cosocket 接收開銷

另一個顯著的 CPU 消耗點是 cosocket 接收操作，佔用了約 16% 的 CPU 時間：

ngx_stream_lua_socket_tcp_receive
  -> ngx_stream_lua_socket_tcp_receive_retval_handler
  -> ngx_stream_lua_socket_push_input_data
  -> luaL_addlstring [/etc/nginx/luajit/lib/libluajit-5.1.so.2.1.0]

分析顯示客戶使用的是較老版本的 LuaJIT，而最新版已對此進行了最佳化。

修復：三項最佳化與各自的實測收益

基於 OpenResty XRay 的深度分析結果，我們的技術團隊為客戶制定了針對性的最佳化方案：

拉平 Worker 程序間的負載分配（提升 20–30%）

透過配置調優解決了 worker 程序間負載不均的問題，顯著改善了系統資源利用效率，整體效能提升 20-30%。

削減 JSON 解析瓶頸 60% 以上的 CPU 消耗

針對識別出的 JSON 處理效能瓶頸，我們提供了多層次的最佳化策略：

資料處理流程重構，減少不必要的計算開銷
智慧快取機制設計，大幅降低重複操作成本
配置管理最佳化，提升系統響應效率

透過這些最佳化，核心瓶頸的 CPU 消耗降低了 60% 以上，系統吞吐量獲得顯著提升。

升級執行時技術棧（額外提升 5–10%）

基於版本相容性分析，我們為客戶規劃了技術棧升級路徑，進一步最佳化底層元件效能，額外獲得 5-10% 的效能提升。

這個案例展示了 OpenResty XRay 在複雜效能問題診斷中的強大能力，能夠精確定位到程式碼級別的效能瓶頸，為最佳化提供明確方向。

總結：OpenResty XRay 幾分鐘內的發現

火速精準定位全部效能瓶頸
深入到程式碼級別，發現傳統監控根本看不到的問題
核心 CPU 佔用降低超過 60%，系統整體效能提升 20%~30%
找出 JSON 解析高達 60% 的 CPU 消耗，直擊效能瓶頸
發現 worker 配置嚴重失衡，負載分配極不合理
排查出老舊元件拖累整體效能，及時升級調整
運維效率大幅提升，為客戶節省了可觀的人力和成本投入
全程使用火焰圖視覺化，效能問題一目瞭然，最佳化方向清晰可量化

在今天這個系統架構複雜、業務高併發的時代，效能問題往往不是表面現象，靠傳統監控很難找出真正的根源。OpenResty XRay 作為業界領先的動態追蹤平臺，能幫技術團隊快速深入到問題核心，制定精準、可落地的最佳化方案。

如果您也想讓系統跑得更穩、更快、更節省。或者希望提前進行一次深度效能最佳化體驗，歡迎申請產品試用。讓 OpenResty XRay 成為你團隊手裡最值得信賴的利器。

立即申請 OpenResty XRay 試用

常見問題

為甚麼個別 Nginx worker 程序的 CPU 佔用遠高於其他程序？

在本案例中，所有監聽埠都未啟用 reuseport 選項，請求無法均勻分配到各個 Nginx worker 程序——部分 worker 佔用率過高，其餘相對空閒。對負載分配相關配置調優後，資源利用效率明顯改善，整體效能提升 20–30%。

如何找出 Nginx / OpenResty Lua 程式碼中的 CPU 消耗點？

用兩個層級的火焰圖逐層收窄。本案例中，OpenResty XRay 的 C 級火焰圖顯示約 60% 的 CPU 時間在 cjson 模組內；Lua 級火焰圖進一步定位到 cjson_decode 約佔 60%、shcache.lua:load 約佔 30%，而核心業務邏輯 dns_server.lua 僅約 5%。

`cjson_decode` 為甚麼會消耗 60% 的 CPU 時間？

該服務在資料處理路徑上反覆承擔 JSON 解析的開銷，使 cjson_decode 成為最大的單一 CPU 消耗點。透過重構資料處理流程、並設計智慧快取機制降低重複操作成本，核心瓶頸的 CPU 消耗降低了 60% 以上。

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