サーバーと仮想マシン

ホスティング運用における高負荷時のCPUコンテキストスイッチングの理解と最適化

高負荷時に威力を発揮 コンテキストの切り替え ホスティング作業において、CPU時間が実際の作業に流れているのか、スレッド間の切り替えに浪費されているのか。ウェブアプリやショップ、APIが確実に反応し、CPUの使用量を減らせるように、症状を認識し、原因を見つけ、切り替えコストを削減する方法を紹介する。 レイテンシー 生成する。.

中心点

以下のキーポイントは、日常的なホスティングにおける分析と最適化のための共通スレッドを形成する。.

為替コスト スレッドによって増加し、すぐに待ち時間につながる。.
症状ジッター、503s、目立つcs値として表示される。.
Linuxスケジューラ と優先順位は、公平性と応答時間をコントロールする。.
チューニング ワーカー数、キャッシュ、制限、アーキテクチャなど。.
モニタリング cs、RPS、エラーコードを使用することで、ブラインド飛行を防ぐことができる。.

ホスティングにおけるコンテキストの切り替えにかかる実際のコスト

各変更は、レジスタ、スタックポインタ、プログラムカウンタを保存し、ステートをリロードします。これは、並列実行中のWebサーバー、PHP-FPM、データベース、キューでは不可能です。 オーバーヘッド が生成される。並列度が上がれば、タイムスライスは縮小し、キャッシュラインはより頻繁に無効化され、CPUはアプリケーションロジックではなくスケジューラーに顕著な時間を費やすことになる。よくログを見ると、1秒あたりのリクエストはほとんど増えていないのに、cs/sは急増している。 CPU時間. .共有やコンテナのセットアップは、多くの隣人が割り込み、I/O、追加プロセスを生成するため、これを悪化させる。ここでワーカーを増やし続けると、スイッチングの嵐を引き起こし、レスポンスタイムの変動とコスト増という代償を払うことになる。.

例えば、コンテキスト・スイッチが2～5μsで、システムが150,000cs/sを生成する場合、1秒あたり0.3～0.75CPU秒が消えることになる。500,000cs/sになると、あっという間に数コアがほとんど管理のみに使われることになる。この経験則に基づく計算は、隠れたコストを具体化するのに役立つ。.

また SMT/ハイパースレッディング 2つの論理スレッドがキャッシュと実行ユニットを共有する。物理コアあたりのアクティブなスレッド数が恒常的に2つを超えると、同じリソースを奪い合うようになり、スケジューラが頻繁に変更される一方で、スレッドあたりの実際の進捗は減少する。そのため、私はワーカーを論理的ではなく 物理コア そして、待ち時間のピークが発生したときのキャッシュ・ミス・レートを特に調べる。.

症状を認識するシステムが遅くなるとき

まず、%のCPU使用率が60-80であるにもかかわらず、応答時間が変動していることを確認する。 ジッター が目立つ。繰り返される503エラーは、プロセスやワーカーの制限を使い果たし、スレッドがクリーンに動作する代わりに互いに競合していることを示すことが多い。vmstat、pidstat -w、sar -wのようなツールは、cs/sだけでなく、プロセスごとの自発的・強制的な切り替えを表示するので、ノイズの多い犯人をすぐに見分けることができる。秒あたりのリクエスト数が比例して増加することなく、cs/sが大幅に増加した場合、あまりにも多くの管理が堂々巡りになっており、実際のペイロードは不足している。共有環境では、プロセス、CPU分数、I/Oのフェアユース制限も有効で、ボトルネックをより早く気づかせ、長期的に減らすことができる。 パフォーマンス がかかる[3][4]。.

も使っている。 PSI（圧力失速情報） via /proc/pressure/cpu: 10s/60s/300sカット値が持続的なCPUプレッシャーを示している場合、総負荷が中程度であっても、ランキューに仕事が溜まっている。cgroup環境では、throttle_countの増加は、CFSクォータのスロットリングを示し、強制スイッチとジッタを増加させる。ksoftirqdのピークが並行して発生する場合、ネットワークやストレージの割り込みがスイッチのドライバーになることが多い。.

さらなる注意点：top/htop においてコアあたりの実行可能カウントが恒常的に高い (>2)、APM において 95th/99th パーセンタイルが強くばらつく、pidstat において多数の 不随意-変化が顕著である。これをまとめると、IO待ち（自発的）に対処する必要があるのか、CPU不足（強制的）に対処する必要があるのかが明確になる。.

Linuxのスケジューラを正しく評価する

プリエンプティブなLinuxのスケジューラは、CFSを介して公平にプロセスを計画し、優先順位、ナイス値、I/Oやネットワーク割り込みに反応する。 応答時間 がある。短命なタスクが多いホスティングスタックでは、タイムスライスが縮小し、コンフィギュレーションが奔放なプロセスを開始する際に、頻繁なコンテキストスイッチを余儀なくされる。私は、重要なパスがキューで滞留しないように、データベースとウェブワーカーの優先順位を明確にしている。より深く掘り下げたいのであれば、以下の記事で選択肢や代替案を見つけることができる。 CFSと代替医療, これは、ホスティングにおける副作用に焦点を絞ったものである。高密度での公平性が最も重要な要素であるため、CFSに過度の負担をかけないことが重要である。 レイテンシー を散乱させ、スループットを手放す。.

スケジューラーの粒度にも注意を払っている： sched_min_granularity_ns そして sched_wakeup_granularity_ns は、スレッド同士が入れ替わる速さに影響する。タイムスライスが小さすぎると切り替え速度が速くなり、大きすぎるとインタラクティブなワークロードの待ち時間が長くなります。共有コアやコンテナコアでは、私は通常デフォルトにこだわり、ワーカー数で負荷を調整します。.

と一緒に CPUとの親和性 NIC割り込み（RPS/XPS）を特別に分散させながら、ウェブワーカーとDBスレッドを異なるコアグループに固定することで、不正なキャッシュ共有を減らすことができます。また、NUMAノート（ローカルメモリ）にも注意を払っています：スレッドがソケット経由で移行される場合、レイテンシとコンテキストスイッチが増加します。ヘルプ ヌマクトル-ポリシーと不要なスレッドマイグレーションの回避。.

測定としきい値：本当に重要な数字

私はコンテキスト・スイッチングを単独で評価することはなく、常にペイロード、エラーコード、プロセス数と一緒に評価している。 トレンド が見えるようになる。各変更の後、きれいなビフォー／アフター比較をすることで、誤解を防ぐことができる。出発点として、cs/sが数千程度であれば、クリティカルではないとみなされることが多い。I/O負荷の高いプロセスにおける自発的な変更は正常であり、CPU負荷の高いタスクにおける強制的な変更は警告信号である。次の表は、主要な指標を分類し、私が日常的に使用している代表的な指標を示したものである。 ボトルネック をつかむ。.

指標	工具	ヒント	参考値／解釈
cs/s（合計）	vmstat, sar -w	システム全体の変化率	RPS引き上げなしで急上昇＝管理間接費
自主的／自発的	pidstat -w	I/O待ちとタイムアウトの区別	CPUバウンドタスクの多くの強制変更は重要である。
実行可能なプロセス	トップ/トップ, ロード	CPUコアでのスネーク長	恒常的に高い = ワーカー/スレッドが多すぎる
HTTP 5xx/503	アクセス/エラーログ	制限、タイムアウト、バックプレッシャー	負荷のピーク＝作業員またはDBの限界に達する
RPS/TPM	APM/NGINX/DB	csに関連するペイロード	csはRPSよりも速く増加する＝非効率

いくつかのヒューリスティックがその価値を証明している：コアあたりの実行キューの長さは、理想的には1に近い。cs/sが5桁から6桁前半であれば、大型ホストでも可能だが、ペイロードに合わせてスケールしなければならない。大まかなコスト計算：cs/s×2-5μsは、管理で何CPU秒消えるかを示しており、ユーザーが気づく前の初期指標となる。.

私はこのビューをパーセンタイル（p95/p99）と「リクエストあたりのcs」という関係で補足している。チューニング後、この指標が安定しているか下がっていれば、その対策は効果的だった。上昇した場合は、クリティカルパスを緩和することなく、より多くのスレッドが作成されただけであることが多い。.

日常生活における原因とその解消法

溢れかえる PHP FPM プール、多すぎるキューコンシューマ、不必要な cron の実行は、プロセスを増やし サイクロン. .CMSのヘビー級プラグインは、DBクエリとバックグラウンドジョブをスタックし、キャッシュしたり、古くなったエクステンションを削除したりすることで、よりスムーズに実行される[1][3]。ページとオブジェクトのキャッシュがない場合、すべてのリクエストはダイナミックチェーン全体を通過しなければならず、さらにスレッドをトリガーします[6]。私は、CPUコアが同じコンテキストでより長く計算できるように、クリーンなインデックス、無駄のないクエリ、並列ワーカーの制限に頼っている。こうすることで、コアパスは予測可能なままとなり、レイテンシは低下し、cs/sは実際の計算に近づく。 ペイロード.

言語やランタイムの特殊性もある：Node.jsのブロッキングCPUタスクはイベントループを詰まらせる。ワーカースレッドやキューへのアウトソーシングはここで役立つ。JVMベースのサービスでは、GCのピークがスレッドを一時停止させることがあり、これが下流のワーカーをバックアップさせ、スイッチングレートを押し上げる。PHPでは、FPMの低速ログが異常値を発見し、高価なIO操作や欠陥のあるプラグインと相関することが多い。.

もう一つのパターンは、バッチジョブでの過度の並列処理だ。同じテーブルを100スレッドで並列処理する代わりに、シャーディングやパーティションを使ってスケールしたり、同時実行を制限してランタイムを最小に拡張する。.

サーバー構成：ワーカー、プール、制限

アクティブなワーカーの合計が物理コア数とほぼ一致するように PHP-FPM を調整します。 コンフリクト 原因Apache/Nginx には現実的なワーカーとコネクションの制限が与えられているので、スケジューラーに負荷が殺到することはなく、キューがスムーズに処理されます。MySQLやPostgreSQLのようなデータベースは、最大接続数がRAMやCPUの容量と一致し、長いトランザクションが避けられれば、よりスムーズに動作します。スイッチング・コストを削減するための実践的なヒントを、以下の記事にまとめました。 CPUオーバーヘッド・チューニングそのため、労働者の数、プール、バックプレッシャーに目を光らせています。プロフェッショナルなプロジェクトを運営する人たちは、通常、より安定した運営を行い、高性能な料金体系と公平な制限で勝利を収めています。 応答時間.

微調整の実際

PHP-FPM: pm = 静的/オンデマンド（トラフィックプロファイルによる）；; pm.max_children ~ コア, pm.max_requests 漏れ防止用、, process_idle_timeout アイドルコストに対して。アイドルプロセスが多すぎると、何のメリットもなくスイッチが増える。.
Nginx： worker_processes 自動, 常識的 ワーカーコネクション, keepalive_requests とアップストリーム・キーパライブにより、接続のセットアップと切断の回数を減らすことができます。. レツレポート 労働者により公平に負荷を配分する。.
Apache: 混在ワークロードにおいてMPMイベントがプレフォークを上回る。.
DB：中程度 最大接続数, 接続プールと短いトランザクション。MySQLではスレッドプールが、PostgreSQLではプロキシ/プーリングがプロセスの洪水を回避するのに役立つ。.
システム： ulimit -n とsystemdが適切に制限しているが、バックログ（例えば. net.core.somaxconn待ち行列は平滑化され、キャパシティの代わりにはならない。.

混雑のないアーキテクチャとスケーリング

インスタンスを限界までプッシュするのではなく、複数のサーバーやコンテナにリクエストを水平に分散させることで、インスタンスへのリクエストを最小限に抑えます。 為替レート ホストあたりの消費電力は顕著に削減される。非同期キューを持つマイクロサービスは作業ステップを切り離すので、長時間実行するタスクが同時にCPU時間を奪い合うことはない。エッジでのレート制限により、ワーカーを疲弊させ503を引き起こすようなリクエストの殺到を防ぐことができる。キューにおけるバックプレッシャーは、プロデューサがコンシューマが実際に処理する量と同じだけの仕事しかセットしないようにする。明確な制限があることで、スケジューラはより予測可能であり続け レイテンシー より均等である。.

サイズ計画には、リトルの法則（L = λ - W）を使う。ステージごとに許容される同時実行数は、到着率と希望する応答時間によって決まる。各ステージ（ウェブ、アプリ、DB、キュー）が独立して安定を保つように上限を設定する。こうすることで、ある段階での最適化が、次の段階での変化の嵐につながることを避けることができる。.

コンテナやオーケストレーション環境では、CPUを考慮する。リクエスト そして制限厳しすぎるクォータはスレッドを周期的にスロットルし、強制切り替えの数を増やす。私は、典型的なバースト以上のリミットを設定し、CFSクォータのリミットが毎分ヒットする前に水平方向にスケールしています。オートスケーリングは、（平均値だけでなく）パーセンタイルとキューの長さを評価する必要があります。.

割り込み、I/O、ネットワーク効果

コンテキスト・スイッチの多くは、ネットワークやストレージからの割り込みによって引き起こされる。 ソフティアークス トリガー。高いPPSレート、TLSハンドシェイク、小さなパケットはプレッシャーを増大させる。これが、私がバッチ処理、キープアライブ、賢明なバッファを使う理由だ。NVMeはレイテンシーを改善するのに役立つが、キューの規律がなければ、高速I/Oは待機スレッドと実行スレッド間のコンテキストスイッチを増やすだけだ。Nagleのような効果をスロットルし、効率的なソケットオプションを使えば、不必要なスイッチの数は顕著に減る。ドライバとIRQのトピックをさらに掘り下げたい場合は、以下の記事でコンパクトな実践的知識を見つけることができる。割り込み処理, これは、IRQアフィニティ、CPU負荷、IRQの間の関係を分析するものである。 スループット と説明した。

私はまた、コア間のNICキューの分散（RPS/XPS）、カスタマイズされた割り込みの合体、賢明なMTUにも注意を払っている。短いコネクション（キープアライブの欠落など）が多いと、ハンドシェイクやコンテキスト・スイッチが増えるが、セッション再開やコネクションの再利用はまさにそれを防いでいる。ストレージ側では、書き込みの結合、技術的に必要な場合のみ短いフラッシュ間隔、プロデューサーパスのバックプレッシャーによって、同期のピークを減らしている。.

多忙なエッジセットアップでは、多重化と再利用が効果的になるようにTLSパラメータとHTTP/2/3のコンセプトを選択する価値がある。目標は変わりません: リクエストあたりのコネクションライフサイクルを減らし、カーネル遷移を減らし、スイッチングレートを下げることです。.

モニタリングとオペレーション：対応するのではなく、コントロールする

CPU、RAM、I/Oだけでなく、cs/s、プロセス数、応答時間についてもアラームを定義しています。 アノマリー を早期に発見することができます。キャンペーンやリリースの前の負荷テストは、ユーザーが気づく前に、不適切なワーカー数やタイマー、DBの制限を発見します。私は変更を徐々に展開し、改善を確実に測定できるようにメトリクスを比較します [2][3][6]。APM、ログ、カーネル統計を、チェックアウト時間やAPIレイテンシなどのビジネス・メトリクスで補足することで、テクノロジーとベネフィットが一体となるようにしています。定期的にチェックすれば、パターンをいち早く認識し、そのパターンを維持することができる。 応答時間 一定している。

私は、p95/p99レイテンシによってSLOを明示的に策定し、アラームを設定している。 燃焼率 (エラーバジェットの消費速度）。ダッシュボードは、cs/sとRPS、エラーコード、キューの長さ、PSIを関連付ける。これにより、cs/sの急上昇が実作業の増加によるものなのか、それともプラットフォームが管理作業に溺れているのかを確認することができる。この共通のイメージは、盲目的なチューニングを防ぐ。.

運用中は、変更後に一定の観察窓を設け（15分／60分／180分など）、ロールバックの基準を設定している。リクエストあたりのcs „が悪化したら、まず同時実行率を下げ、バックプレッシャーが効いてからさらにネジを締める。.

AIと高負荷ワークロードの分離

AI関数は、リクエストごとにCPUコアに長い負荷をかけるため、古典的なウェブリクエストが並行して待機しなければならない場合、コンテキストスイッチが発生する[2]。CPU負荷を最小化するために、推論の多いパスを別のサービスに分離し、キューを使用し、フロントエンドのウェブサーバーを長時間実行タスクからできるだけ解放しておく。 レイテンシー スムージング。AIバックエンドのための専用リソースは、短いHTMLリクエストが計算集約的な呼び出しの影で立ち往生するのを防ぐ。レート制限とタイムアウトは、予測可能性が維持されるように、計算負荷の高いパスのための明確な通路を設定します。この分離を厳密に実施することで、ウェブ・サーバー上のcs/sを削減し、信頼性の高い 応答時間.

実用的には、推論用のデプロイユニットとキューを分離すること、モデル/エンドポイントごとにハードな同時実行数制限を設けること、そして可能であれば、次のことを意味する。 ストリーミング ブロッキングバッファリングの代わりに。私は、バッチサイズと並列性を測定している。私は、スイッチングコストが高いフラッターよりも、ピークレートが少し低い安定したものを好む。.

10分でできるクイックウィンのチューニング

vmstat、pidstat -w、そしてログを見ることから始め、cs/sとリクエストを比較し、多くのプロセスを強制的に切り分けます。変更. .その後、PHPのFPMワーカーとWebサーバーのワーカーをコア数レベルまで減らし、過負荷の代わりにキューが発生するかどうかをチェックする。動的なパスの前にページキャッシュやマイクロキャッシュを置くと、動的な実行が少なくて済むため、すぐに負荷が減る。データベースでは、適度な最大接続数でピークを減らし、コアを頻繁にブロックする長いトランザクションをチェックする。最後に、RPSとレスポンス・レートを再度テストして効果を定量化し、次のステップを決定する。 ステップ を計画する。.

クイックチェック：cs/s対RPS、p95/p99レイテンシー、PSI CPU。すべてが仕事の代わりに管理に向いているか？同時実行を減らす。.
トップ違反者：プロセスごとのpidstat -w、任意と強制の比較。多くの強制的な変更で即座にスロットルCPUバウンド。.
ウェブ/アプリ：物理コアへのワーカーバック、キープアライブの有効化、アップストリーム・キープアライブのチェック、ホットパス上のマイクロキャッシュ。.
DB：接続の最大化、長いトランザクションの特定、インデックスのチェック、キュー・コンシューマーを要件に合わせて調整。.
ネットワーク/IRQ：IRQの分配をチェックし、小さな接続が多すぎないようにする。.
比較：「リクエストあたりのシーエス数」と、その前後のパーセンタイル。.

簡単にまとめると

効率的 コンテキストの切り替え ホスティングにおけるCPU時間は、生産的に働くか、管理に浪費されるかを決定する。ジッター、503s、高い cs/s などの症状をいち早く認識することで、待ち時間とコストを節約できます。適切なワーカー数、一貫したキャッシュ、明確な制限、クリーンなアーキテクチャにより、プロセスは計算可能なまま維持されます。モニタリング、負荷テスト、反復的な変更により、すべての測定が測定可能で、厄介な驚きを引き起こさないようにします。たとえば webhoster.de では、レスポンスタイムが一定に保たれるように、また、コスト削減のために、私は公正な制限を設けた強力な料金体系を採用しています。 ユーザー・エクスペリエンス 右だ。