Pleskウェブサーバ

スレッド競合：Web サーバーの速度を低下させ、パフォーマンスを低下させる原因

スレッド競合 Webサーバーの速度を低下させます。これは、スレッドがロック、キャッシュ、カウンタなどの共有リソースを競合し、互いにブロックし合うためです。この競合がどのように ウェブホスティングのパフォーマンス その背景にある同時実行の問題と、確実に効果のある実用的な対策について解説します。.

中心点

錠前ボトルネック：同期はデータを保護しますが、待ち時間が発生します。.
スケジューラ負荷が増加：コアあたりのスレッド数が多すぎると、スループットが低下します。.
回転位置検出 およびレイテンシの影響を受ける：競合により、1 秒あたりのリクエスト数が著しく減少します。.
イベント駆動型 サーバーのサポート：NGINX と LiteSpeed はブロックの回避に優れています。.
モニタリング まず、目標指標を優先し、競合は文脈に応じてのみ評価する。.

Webサーバーでスレッド競合を引き起こす要因

私はこう定義する争いスレッド間の同期リソース（ミューテックス、セマフォ、共有キャッシュなど）の競合として。各スレッドには独自のコールスタックがありますが、多くのリクエストが同じロックにアクセスすることがよくあります。これによりデータエラーは防止されますが、待ち時間が大幅に長くなります。動的なページアクセスでは、PHP-FPM、データベース接続、セッション処理で特にこの現象が多く発生します。負荷がかかると、スレッドはキューに待機します。 レイテンシー 上昇し、スループットは低下します。.

実用的な例を挙げてみましょう。100 人のユーザーが同時に動的なリクエストを開始し、全員が同じキャッシュキーを必要としています。同期を行わないと、レースコンディションが発生するリスクがあり、同期を行うと輻輳が発生します。その結果、スレッドがブロックされ、コンテキストの切り替えが増加し、実行キューが拡大します。これらの影響が相まって、パフォーマンスが低下します。 回転位置検出 明らかです。まさにこのパターンが、ウェブサーバーのベンチマークで定期的に見られます [3]。.

競合が応答時間とスループットを低下させる理由

待機スレッドが多すぎると、 CPU 不必要なコンテキストの切り替え。切り替えには毎回クロックサイクルがかかり、単位時間あたりの有効作業量が減少します。さらにスケジューラの負荷がかかると、システムはスラッシング状態に陥ります。その結果、SQL または PHP-FPM プールで非収束メッセージが発生し、IO パスと演算パスが激しく衝突します [5]。その結果、応答時間が著しく長くなり、変動が生じます。 P95-レイテンシー。.

測定では、効率的なサーバーは数千 RPS の範囲にあるのに対し、競合に悩まされているセットアップは明らかに低下しています [6]。この影響はリクエストだけでなく、CPU および IO パスにも及びます。IO 完了ポートなどの非同期コンポーネントでさえ、競合率が上昇しても、必ずしも全体的なパフォーマンスが低下するとは限りません。コンテキストが決め手となります [3]。そのため、私はスループットや応答時間などの目標指標に焦点を当て、競合値は常に全体像の中で評価しています。この視点により、誤警報を防ぎ、真の問題に注意を向けさせることができます。 ボトルネック.

測定可能な効果とベンチマーク

私は定量化する争いスループット、レイテンシ、CPU 使用率による影響。この表は、負荷がかかった場合の典型的なパターンを示しています。RPS は低下し、レイテンシは上昇し、CPU 使用率は上昇します [6]。これらの数値は、アプリのロジックやデータパスによって異なりますが、明確な傾向を示しています。チューニングの決定については、コードやカーネルのメトリクスを詳しく調べる前に、この概要で十分だと思います。重要なのは、対策が 応答時間 コストを削減し、スループットを向上させます。.

ウェブサーバー	RPS（通常）	RPS（高競合）	待ち時間 (ms)	CPU使用率
アパッチ	7508	4500	45	高い
NGINX	7589	6500	32	低い
ライトスピード	8233	7200	28	効率的

私はこのような表を単独で読むことは決してありません。RPS は正しいが、CPU が限界に達している場合、スレッドや IO が制限要因となります。 スケーリング. RPS が低下し、レイテンシが同時に上昇した場合、私はまずアーキテクチャの変更に取り組みます。小さなコードの修正では、グローバルロックの混雑を部分的にしか解決できない場合が多いのです。スレッドモデルとプロセスモデルを明確に分離することで、 安定性, 生産システムに必要なもの [6]。.

Web環境における典型的な原因

グローバル錠前セッションやキャッシュは、多くの場合、最大の渋滞を引き起こします。1 つのホットスポットロックだけで、多くのリクエストが保留されます。コアあたりのスレッド数が多いと、スケジューラが過負荷になるため、この問題はさらに深刻になります。ループ内の同期化された IO 呼び出しは、さらにブロックを引き起こし、不適切な場所でワーカーの速度を低下させます。さらに、データベースとキャッシュの衝突も発生します。 レイテンシー 各リクエストを拡大する [2][3][5]。.

サーバーアーキテクチャも影響します。Apache の prefork または worker は、その性質上、より強いブロックを行います。一方、NGINX や LiteSpeed などのイベント駆動型モデルは、待機状態を回避します [6]。 PHP-FPM プールでは、pm.max_children の値が高すぎると、不必要なロック圧力が発生します。WordPress では、キャッシュされていないクエリは、DB およびキャッシュの競合を増加させます。私は、ハードウェアをアップグレードする前に、まずこの問題に対処します。 IOPS またはコアを使用します [2][6][8]。.

競合が実際に役立つ場合

上昇するすべての争い-レートは悪い。IO Completion Ports や .NET の TPL などのスケーラブルな IO モデルでは、コンテンスがスループットと並行して増加する場合がある [3]。そのため、私はまず目標指標（RPS、P95 レイテンシ、同時ユーザー数）を測定する。コンテンスの増加に伴い RPS が低下した場合は、直ちに対処する。しかし、RPS が上昇し、 レイテンシー, 、システムがより効率的に動作するため、より高い競合値を受け入れます [3]。.

この視点は、盲目的な最適化を防ぐのに役立ちます。私は、コンテキストのない個々のカウンターを追跡することはありません。反応時間、スループット、エラー率が私の基準となります。次に、プロファイリングによってスレッドを確認し、ロック、プール、IO のどれがボトルネックになっているかを判断します。そうすることで、次のような事態を回避しています。 マイクロ最適化, 目標を見失っている人たち。.

スレッド競合に対する戦略：アーキテクチャ

私は減らす錠前まずはアーキテクチャについて。NGINX や LiteSpeed などのイベント駆動型ウェブサーバーは、ワーカーのブロックを回避し、IO をより効率的に分散します。ホットスポットによってすべてが停止しないように、キープレフィックスでキャッシュを分割しています。PHP では、積極的な OPcache 戦略を採用し、DB 接続を短く保っています。スレッドプールでは、コア数に注意し、ワーカーを制限して、 スケジューラ 倒れない [5][6]。.

具体的な設定はすぐに役立ちます。Apache、NGINX、LiteSpeed のセットアップについては、実証済みのスレッドおよびプロセスルールに従っています。プールサイズ、イベント、MPM に関する詳細については、以下に示すガイドが参考になります。スレッドプールを正しく設定する. 私は、ベンチマークの理想値ではなく、実際の負荷を考慮しています。レイテンシが低下し、 回転位置検出 安定して上昇しているから、私は正しい軌道に乗っている。.

スレッド競合に対する戦略：コードと構成

コードレベルでは、グローバルを避けています。錠前可能であれば、アトミック操作やロックフリー構造に置き換えます。ホットパスを分散して、シリアル化を少なくします。Async/await またはノンブロッキング IO により、クリティカルパスから待ち時間を削減します。データベースでは、読み取りパスと書き込みパスを分離し、クエリキャッシュを意図的に使用します。これにより、キャッシュおよび DB ロックへの負荷を軽減し、パフォーマンスを向上させます。 応答時間 顕著である [3][7]。.

PHP-FPM では、プロセス制御を意図的に操作します。パラメータ pm、pm.max_children、pm.process_idle_timeout、および pm.max_requests は、負荷分散を決定します。pm.max_children の値が高すぎると、必要以上の競合が発生します。適切な初期設定は次のとおりです。 PHP-FPM pm.max_children コア数とメモリフットプリントに関連して。これにより、 プール 反応性が高く、機械全体をブロックすることはありません [5][8]。.

モニタリングと診断

私は次のように始める。 ゴール-メトリクス：RPS、P95/P99レイテンシ、エラー率。その後、コアあたりのコンテション/秒、%プロセッサ時間、キューの長さを確認します。コアあたりのコンテションが100秒以上になると、RPSが上昇せず、レイテンシが低下しない限り、アラームを設定します[3]。視覚化には、スレッドとキューを明確に相関させるメトリックコレクターとダッシュボードを使用します。キューに関する良い入門書としては、この概要があります。サーバーキューについて理解する.

アプリケーション側では、トランザクションに沿ってトレースを使用しています。これにより、重要なロック、SQL ステートメント、キャッシュアクセスをマークします。そうすることで、スレッドがどこで、どのくらいの時間ブロックされているかを正確に把握できます。テストでは、並列性を段階的に高め、いつ レイテンシー 折れる。これらの点から、次のチューニングの段階を導き出します [1][3]。.

実例：負荷がかかった状態のWordPress

WordPress で作成 ホットスポット 多くの DB クエリを実行したり、グローバルオプションをロックしたりするプラグイン。OPcache を有効にし、Redis を使用してオブジェクトキャッシュを設定し、プレフィックスでキーをシャードします。匿名ユーザー用のページキャッシュは、動的負荷を即座に軽減します。PHP-FPM では、プールを拡張する代わりに、コア数よりわずかに大きいサイズに設定しています。これにより、 回転位置検出 安定しており、応答時間を予測可能[2][8]。.

シャーディングがない場合、多くのリクエストが同じキーロックの前に立ち往生します。その結果、トラフィックのピークだけでブロックの連鎖が発生します。スリムなクエリ、インデックス、短いトランザクションによって、ロックの継続時間を短縮します。スタンピディングを回避するため、ホットキーの TTL を短く設定します。これらの手順により、争い目に見えて、ピーク時の予備力を解放します。.

迅速な成功のためのチェックリスト

私は次のように始める。測定：RPS、レイテンシ、エラー率のベースラインを設定し、その後、再現性のある負荷テストを実施します。その後、コアあたりのスレッド数を減らし、現実的なプールサイズを設定します。続いて、ホットパス内のグローバルロックを削除するか、より細かいロックに置き換えます。サーバーをイベント駆動型モデルに変更するか、適切なモジュールを有効にします。最後に、ダッシュボードアラートと繰り返しテストによって改善点を確保します。 テスト [3][5][6]から。.

問題が解決しない場合は、アーキテクチャのオプションを優先します。水平スケーリング、ロードバランサーの使用、静的コンテンツの外部化、エッジキャッシュの利用などです。次に、リードレプリカと明確な書き込みパスを使用してデータベースを分散します。IO が不足している場合は、ハードウェアが役立ちます。NVMe SSD やコア数の増加により、IO および CPU のボトルネックが緩和されます。これらの手順で問題が解決しない場合にのみ、次のステップに進みます。 マイクロ-コードの最適化 [4][8][9]。.

ロックのタイプを正しく選ぶ

誰もが ロック 負荷がかかると同じ挙動になります。排他的なミューテックスはシンプルですが、読み取り負荷の高いパスではすぐにボトルネックになります。. リーダーライターロック 多くの読み取りでは負荷を軽減しますが、書き込み頻度が高い場合や不公平な優先順位付けが行われる場合、ライター飢餓を引き起こす可能性があります。スピンロックは、非常に短いクリティカルセクションでは有効ですが、競合が激しい場合、CPU 時間を消費します。そのため、クリティカルセクションが長くなる場合は、Futex をサポートするスリーププリミティブを使用することを好みます。ホットパスでは、 ロックストライピング また、すべてのリクエストが同じロックを必要としないように、データを（ハッシュプレフィックスなどで）分割します [3]。.

見過ごされがちな要素は、 アロケーター. 。中央ロック（ライブラリなど）を備えたグローバルヒープは、アプリケーションコードがクリーンであるにもかかわらず、待機状態を引き起こします。スレッドごとのキャッシュや最新の割り当て戦略により、このような衝突は減少します。 PHP スタックでは、高価なオブジェクトが再利用されるか、リクエストのホットパス外でプリヒートされるように注意しています。また、ダブルチェックロックの落とし穴は避けています。初期化は、起動時、またはスレッドセーフなパスを 1 回だけ使用して行います。.

オペレーティングシステムおよびハードウェアの要因

OS上で再生 NUMA 役割を果たします。プロセスがノード全体に分散すると、クロスノードアクセスが増加し、L3 およびメモリの競合が発生します。私は、ワーカーを NUMA ローカルに優先的にバインドし、メモリアクセスをノード近くに維持しています。ネットワーク側では、1 つのコアがすべてのパケットを処理して Accept パスを混雑させることを避けるため、コア間で割り込みを分散しています (RSS、IRQ アフィニティ)。カーネルキューもホットスポットです。リストのバックログが小さすぎる場合や SO_REUSEPORT が欠けている場合は、不必要な Accept 競合が発生しますが、設定が過度に積極的な場合は スケーリング 再びブレーキをかけることができる – 私は反復的に測定と調整を行います [5]。.

VM やコンテナでは、私は次のことを観察しています。 CPUスロットリング およびスティール時間。cgroups での厳しい CPU 制限は、競合のように感じられるレイテンシのピークを生み出します。私は、保証された利用可能なコアに近いプールを計画し、オーバーサブスクリプションを避けています。ハイパースレッディングは、IO 負荷の高いワークロードには役立ちますが、実際のコアの不足を覆い隠してしまいます。ワーカーコアと割り込みコアを明確に割り当てることで、純粋なパフォーマンスよりも P95 レイテンシをより安定させることができます。.

プロトコルの詳細：HTTP/2/3、TLS、および接続

キープアライブ Accept 負荷を軽減しますが、接続スロットを拘束します。私は、少数の長時間実行プロセスが容量をブロックしないように、適切な制限値を設定し、アイドル時間を制限しています。HTTP/2 では、マルチプレキシングによってパイプラインが改善されますが、内部ではストリームがリソースを共有するため、アップストリームクライアント（FastCGI、プロキシプールなど）のグローバルロックがボトルネックになります。パケット損失が発生すると、TCP ヘッド・オブ・ラインが発生し、 レイテンシー 急激に増加。堅牢な再試行と上流区間での短いタイムアウトで補っています。.

時点では ティーエルエス セッションの再開と効率的な鍵のローテーションに注意を払っています。集中化されたチケットキーストアは、慎重な同期が必要であり、そうしないと、ハンドシェイク段階でロックホットスポットが発生します。証明書チェーンはスリムに保ち、OCSP はきれいにキャッシュしています。これらの詳細により、ハンドシェイクの負荷が軽減され、暗号化レイヤーが間接的に Web サーバーのスレッドプールを制限することを防ぎます。.

バックプレッシャー、負荷削減、タイムアウト

どのシステムも無制限に受け入れることはできません。私は 同時実行制限 アップストリームごとに、キューの長さを制限し、予算が使い果たされたら早めに 503 を返します。これにより、レイテンシー SLA が保護され、キューが制御不能に蓄積されるのを防ぎます。. 背圧まず端から始めましょう。小さなアクセプトバックログ、アプリサーバーの明確なキュー制限、短くて一貫性のあるタイムアウト、そしてすべてのホップにわたるデッドラインの伝達です。これにより、リソースが解放され、 ウェブホスティングのパフォーマンス カスケード的に悪化することはない [3][6]。.

キャッシュスタンピードに対しては、私は 合体要求 つまり、同一の高価なミスは計算されたリクエストとして実行され、他のすべてのリクエストは結果を少し待つことになります。ロックホットスポットのあるデータパスでは、次のことが役立ちます。 シングルフライト またはワーカーでの重複排除。低速アップストリーム用のサーキットブレーカーと適応型同時実行（P95フィードバックによる増加/減少）により、厳格な上限を全面的に設定することなく、スループットとレイテンシを安定化させます。.

テスト戦略：負荷プロファイル、回帰保護、テールレイテンシ

私は現実的な 到着率, 固定の同時実行だけでなく。ステップテストとスパイクテストは、システムがいつ限界に達するかを示します。ソークテストは、リークや緩やかな劣化を発見します。調整された省略を避けるため、私は一定の到着率で測定し、実際の待ち時間を記録します。重要なのは、平均値だけでなく、時間枠における P95/P99 です。変更後のクリーンな事前/事後比較により、改善と思われるものが単なる測定上のアーチファクトではないことを確認します [1][6]。.

CI/CDパイプラインでは、私は パフォーマンスゲートロールアウト前の小規模で代表的なワークロード、目標指標を厳密に監視するカナリアデプロイ、および悪化時の迅速なロールバック。SLO とエラー予算を定義し、純粋な競合カウンタが問題ないように見えても、予算を使い切る措置は早期に停止します。.

詳細な分析のためのツール

Linuxでは、私は以下を使用しています。 パーフェクト (オンCPU、, perf sched, パーフェクトロック), pidstat また、eBPF プロファイルを使用して、オフ CPU 時間とロック待機理由を可視化します。CPU およびオフ CPU 上のフレームグラフは、スレッドがブロックされている箇所を示します。PHP では、FPM スローログとプールステータスが役立ちます。データベースでは、ロックテーブルと待機テーブルを確認します。 Web サーバーレベルでは、$request_time をアップストリーム時間と相関させ、ボトルネックが Web サーバーの前か後かを確認します [3][5]。.

私は、すべてのサービスにわたってトレース ID を記録し、トランザクションごとにスパンをまとめます。これにより、グローバルキャッシュロック、接続プールキューの混雑、ソケットバッファのオーバーフローなどがレイテンシの原因であるかどうかを特定します。この情報により、一般的な最適化について手探りで試行錯誤するよりも、最も深刻なボトルネックを的確に特定できるため、時間を節約できます。.

競合を激化させるアンチパターン

スレッドが多すぎる コアあたり：より多くの作業を行うことなく、スケジューラおよびコンテキストスイッチの負荷を発生させます。.
グローバルキャッシュ シャーディングなし：キーは単一競合点になります。.
同期ロギング ホットパス：ファイルロックまたは IO が各リクエストを待機します。.
長い取引 DB内：ロックは不要であり、下流のパスをブロックします。.
無限のキュー: 過負荷を隠して、問題をレイテンシのピークに先送りする。.
„測定基準のない「最適化」：局所的な改善は、しばしば全体的な行動を悪化させることがあります [4][6]。.

実践：コンテナおよびオーケストレーション環境

コンテナでは、以下の点を考慮しています。 CPU およびメモリの制限 厳しい制限として。スロットリングはスケジューラにスタッターを発生させ、それにより見かけ上の競合を引き起こします。私はプールサイズを保証リソースに固定し、オープンファイルディスクリプタとソケットを寛大に設定し、再利用メカニズム（例：SO_REUSEPORT）Accept パスを軽減します。Kubernetes では、レイテンシ SLA を担うノードのオーバーコミットを避け、重要なポッドを NUMA に適したノードに固定しています。.

プローブ（準備状況/稼働状況）が負荷のピークを引き起こさないこと、およびローリングアップデートによってプールが一時的に過負荷にならないことを保証します。テレメトリには専用のリソースが割り当てられるため、メトリックおよびログパスがペイロードと競合することはありません。これにより、 ウェブホスティングのパフォーマンス クラスタが回転またはスケーリングされても安定しています。.

簡単にまとめると

スレッド競合 スレッドが共有リソースを争い、互いに妨害し合うことで発生します。これは RPS、レイテンシ、CPU 効率に影響を与え、動的コンテンツを扱う Web サーバーに特に大きな打撃を与えます。私は、真のボトルネックを特定し、的を絞って解決するために、常に目標指標のコンテキストで競合を評価しています。アーキテクチャの調整、適切なプールサイズ、ロックの少ないデータパス、イベント駆動型サーバーが最大の効果をもたらします。一貫したモニタリング、明確なテスト、実用的な変更によって、私は ウェブホスティングのパフォーマンス 戻って、トラフィックのピークに備えて予備を確保する [2][3][6][8]。.