← 戻る

Nginx Worker の CPU 使用率の偏り：reuseport 未設定と cjson ボトルネックを特定

章亦春投稿日 Jul 2, 2025 更新日 Aug 12, 2026

用時約8分

閲覧数

一部の Nginx worker プロセスだけが CPU を使い切り、他はほぼアイドル状態——このような CPU 使用率の偏りは、リスニングポートで reuseport オプションが未設定であるなど、リクエスト分散側の問題であることが少なくありません。本事例では、OpenResty XRay が DNS サービスの CPU 不均衡の原因を、まさにこの設定漏れと、CPU 時間の 60% を消費する 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` が CPU 時間の 60% を消費

C フレームグラフ分析を通じて、約 60% の CPU 時間が cjson モジュールで消費されていることが分かりました。

Lua フレームグラフから見ると、約 60% の時間が cjson_decode 操作に、約 30% の時間が shcache.lua:load に消費されており、コア業務ロジックである dns_server.lua が消費している時間はわずか約 5% にすぎません。

以上のことから、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 であり、最新バージョンではこの問題が最適化されていることが分かりました。

修正：3 つの最適化とそれぞれの実測効果

OpenResty XRay に基づく深層分析結果をもとに、弊社技術チームは、お客様向けに専用の最適化プランを策定いたしました。

Worker プロセス間の負荷の偏りを是正（20〜30% 向上）

worker プロセス間の負荷不均衡の問題を設定調整により解決し、システムリソースの利用効率を著しく改善しました。これにより、全体的な性能が 20-30% 向上しました。

JSON 解析ボトルネックの CPU 消費を 60% 以上削減

特定された JSON 処理性能のボトルネックに対して、以下の多層的な最適化戦略を提供しました：

データ処理フローの再構築により、不要な計算負荷を削減
インテリジェントキャッシュメカニズムの設計により、重複操作のコストを大幅に削減
設定管理の最適化により、システム応答効率を向上

これらの最適化により、コアボトルネックの CPU 消費が 60% 以上削減され、システムのスループットが顕著に向上しました。

ランタイムスタックのアップグレード（さらに 5〜10% 向上）

バージョン互換性分析に基づき、お客様に技術スタックのアップグレードパスを計画し、基盤コンポーネントの性能をさらに最適化しました。これにより、追加で 5-10% の性能向上が得られました。

このケーススタディは、OpenResty XRay が複雑な性能問題の診断において高い実力を発揮し、コードレベルの性能ボトルネックを正確に特定し、最適化の明確な方向性を提供できることを示しています。

要約：OpenResty XRay が数分で特定した内容

迅速かつ正確にすべてのパフォーマンスボトルネックを特定
コードレベルまで深く掘り下げ、従来の監視では見つけられない問題を発見
コア CPU 使用率を 60% 以上削減し、システム全体のパフォーマンスを 20%〜30% 向上
JSON 解析が CPU 消費の 60% に達していることを発見し、パフォーマンスボトルネックを的確に特定
worker 設定の深刻な不均衡を発見し、負荷分散が極めて非効率であることを確認
全体のパフォーマンスを低下させていた古いコンポーネントを特定し、適切なタイミングでのアップグレードを可能に
運用効率が大幅に向上し、お客様の工数とコストを大幅に削減
全工程でフレームグラフを使用し、パフォーマンス問題が一目瞭然、最適化の方向性が明確かつ定量化可能

システムアーキテクチャが複雑化し、大量の同時アクセスを処理する今日の時代において、パフォーマンス問題は表面的な現象にとどまらないことが多く、従来の監視では真の原因を見つけるのが難しいです。OpenResty XRay は業界をリードする動的トレーシングプラットフォームとして、技術チームが問題の核心に迅速に到達し、正確かつ実行可能な最適化プランを策定するのに役立ちます。

システムをより安定させ、より速く、より効率的に運用したいとお考えの方、または事前に深いパフォーマンス最適化を体験したい方は、ぜひ製品の試用をお申し込みください。OpenResty XRay をチームの最も信頼できるツールにしてください。

OpenResty XRay の試用を今すぐ申請

よくある質問

なぜ一部の Nginx worker プロセスだけ CPU 使用率が高くなるのですか？

本事例では、すべてのリスニングポートで reuseport オプションが未設定だったため、リクエストが各 Nginx worker プロセスに均等に分散されず、一部の worker だけ CPU 使用率が高く、他は比較的アイドル状態になっていました。負荷分散に関わる設定を調整した結果、リソース利用効率が改善し、全体性能が 20〜30% 向上しました。

Nginx / OpenResty の Lua コードで CPU を消費している箇所はどう特定しますか？

2 つのレベルのフレームグラフで段階的に絞り込みます。本事例では、OpenResty XRay の C レベルのフレームグラフで CPU 時間の約 60% が cjson モジュール内にあることが分かり、Lua レベルのフレームグラフでさらに cjson_decode が約 60%、shcache.lua:load が約 30% を占め、コア業務ロジックの dns_server.lua はわずか約 5% であることを特定しました。

`cjson_decode` はなぜ CPU 時間の 60% も消費していたのですか？

このサービスはデータ処理経路で JSON 解析の処理コストが繰り返し発生しており、cjson_decode が単独で最大の CPU 消費箇所になっていました。データ処理フローの再構築と、重複操作のコストを削減するキャッシュメカニズムの設計により、コアボトルネックの CPU 消費は 60% 以上削減されました。

OpenResty XRay について

OpenResty XRay は動的トレーシング製品であり、実行中のアプリケーションを自動的に分析して、パフォーマンスの問題、動作の問題、セキュリティの脆弱性を解決し、実行可能な提案を提供いたします。基盤となる実装において、OpenResty XRay は弊社の Y 言語によって駆動され、Stap+、eBPF+、GDB、ODB など、様々な環境下で複数の異なるランタイムをサポートしております。

著者について

章亦春（Zhang Yichun）は、オープンソースの OpenResty^® プロジェクトの創始者であり、OpenResty Inc. の CEO および創業者です。

章亦春（GitHub ID: agentzh）は中国江蘇省生まれで、現在は米国ベイエリアに在住しております。彼は中国における初期のオープンソース技術と文化の提唱者およびリーダーの一人であり、Cloudflare、Yahoo!、Alibaba など、国際的に有名なハイテク企業に勤務した経験があります。「エッジコンピューティング」、「動的トレーシング」、「機械プログラミング」の先駆者であり、22 年以上のプログラミング経験と 16 年以上のオープンソース経験を持っております。世界中で 4000 万以上のドメイン名を持つユーザーを抱えるオープンソースプロジェクトのリーダーとして、彼は OpenResty^® オープンソースプロジェクトをベースに、米国シリコンバレーの中心部にハイテク企業 OpenResty Inc. を設立いたしました。同社の主力製品である OpenResty XRay（動的トレーシング技術を利用した非侵入型の障害分析および排除ツール）と OpenResty Edge（マイクロサービスおよび分散トラフィックに最適化された多機能ゲートウェイソフトウェア）は、世界中の多くの上場企業および大企業から高い評価を得ております。OpenResty 以外にも、章亦春は Linux カーネル、Nginx、LuaJIT、GDB、SystemTap、LLVM、Perl など、複数のオープンソースプロジェクトに累計 100 万行以上のコードを寄与し、60 以上のオープンソースソフトウェアライブラリを執筆しております。