サーバーと仮想マシン

サーバーCPUアフィニティ：ホスティング運用の最適化

サーバーCPUとの相性 は、固定CPUコアにプロセスを割り当てることで、ホスティングスタックにおけるマイグレーション、コンテキストスイッチ、コールドキャッシュを削減します。このピン留めによって、ウェブサーバー、PHP-FPM、データベース、VM、コンテナにおいて、予測可能なレイテンシー、より高いキャッシュヒット率、一貫したスループットがどのように実現されるかを紹介する。.

中心点

ホスティングにおけるアフィニティを効果的に実施するためのガイドラインとなるのは、以下のような核となる側面である。.

キャッシュの近さ は、待ち時間を最小限に抑え、マルチスレッドワークロードの効率を向上させる。.
計画性 ピン止めにより、P99での外れ値が少なくなり、応答時間が一定になる。.
NUMAの認識 メモリとCPUを結合し、高価なリモートアクセスを削減します。.
Cグループ ノルマ、優先順位、公平な分配で親和性を補完する。.
モニタリング perf/Prometheusを使うことで、マイグレーションやミスを発見できる。.

ホスティングにおけるCPUアフィニティとは？

親和性バインド スレッド を固定コアに割り当て、スケジューラがソケット全体に分散させないようにする。これにより、L1/L2/L3キャッシュをウォームな状態に保つことができる。 ウェブ問い合わせ カウントされる。LinuxのCFSはデフォルトで動的にバランスをとるが、ホットフェーズでは余計なマイグレーションが発生する。私は、スケジューラーを完全にスローダウンさせる代わりに、これらのマイグレーションを特に制限している。CFSの代替案については、こちらで詳しく紹介している： Linuxスケジューラのオプション.

ワークロード分析とプロファイリング

ピンを打つ前に、私は特徴サービスのイベント・ドリブンのウェブ・サーバーでは、コンテキストの変更はほとんど発生しないが、キャッシュ・コヒーレンシの恩恵は大きい。データベースは、集中的な結合やチェックポイントの際のカーネルマイグレーションに敏感である。私はp95/p99レイテンシを測定し、CPUマイグレーションを パーフェクト そしてLLCのミスを探す。それから初めて、私は固定ルールを作成し、ピーク負荷の下でそれをテストする。.

CPUトポロジー、SMT、コアペア

私は物理的なトポロジーを考慮に入れている：コアコンプレックス、L3スライス、そして SMT-兄弟。テールレイテンシが重要なサービスでは、ホットスレッドが実行ユニットを共有しないように、1コアにつき1つのSMTスレッドしか割り当てない。追加スループットの恩恵を受けるバッチジョブでは、SMTはアクティブのままだ。AMD-EPYCでは、CCD/CCXの制限に注意しています：ワーカーはL3セグメント内にとどまり、LLCヒットを高く安定させる。NICを多用するスタックでは、RX/TXキューをコア, で実行される。このペアリングはクロスコアのスヌープを回避し、IRQ、SoftIRQ、アプリ間のパスを短く保つ。.

ウェブサーバーとPHP-FPMのピン留め戦略

ウェブフロントエンドには NGINX レスポンスタイムを一定にするために、例えば0-3といった狭いコアセットを使うことが多い。Node.jsをワーカースレッドで解放し、CPU負荷の高いタスクを自分のワーカースレッドにバインドしている。 カーン. .私はアパッチをイベントMPMに入れ、ショートランキューに厳しい制限をかけている。このようなレイアウトはパイプラインをクリーンに保ち、ジッターを顕著に減少させる。.

アフィニティにおけるカーネルとスケジューラのパラメータ

アフィニティは、カーネルが恒久的に対抗しなければ、より強い効果を発揮する。キャッシュに非常に敏感なサービスに対しては、私は スケジューマイグレーションコスト, そうすることで、CFSがマイグレーションを „安い “と判断する頻度が減る。. sched_min_granularity_ns そして sched_wakeup_granularity_ns ここではA/Bテストを使用する。孤立レイテンシーカーネルには、特に ハウスキーピング-CPUを使用し、RCU/カーネルスレッドをホットコアから離す（特定のホストではnohz_full/rcu_nocbs）。これらの介入は 文脈依存私はワークロード・クラスごとに変更し、分散やスループットが低下した場合は、綿密な監視を行いながらロールバックしている。.

データベースとアフィニティ・マスク

データベースでは、優れた アロケーション オンライン・トランザクション、メンテナンス・ジョブ、I/O処理。SQL Serverはアフィニティ・マスクをサポートしており、それを使ってエンジン・スレッド用のCPUセットとI/O用のCPUセットを別々に定義している。アフィニティ・マスクとI/Oマスクが重ならないようにします。そうしないとホット・スレッドがブロックI/Oと競合します。32コア以上のホストでは、拡張64ビットマスクを使います。これにより、ログフラッシャー、チェックポインター、クエリワーカーを互いにクリーンな状態に保つことができます。絶縁.

ストレージパスとNVMeキュー

時点では blk-mq 私はNVMeとストレージキューをDBワーカーと同じNUMAドメイン内のコアにマッピングしている。ログフラッシュスレッドと関連するNVMeキューIRQは、書き込み確認がソケットをまたいで実行されないように、隣接するコアに配置する。アプリのスレッドと使用頻度の高いストレージIRQが同じコアを共有しないようにしています。キュー数が実際に割り当てられているコア数と一致するように、マルチキュー・スケジューラーを使用しています。多すぎるキューはオーバーヘッドを増やすだけで、少なすぎるとロックの滞留が発生します。.

仮想化、vCPUのピニングとNUMA

KVMまたはHyper-Vの場合、私は次のようにします。 vCPU を物理コアに移動させることで、時間泥棒を防いでいる。IOがアプリのスレッドをスロットリングしないように、vhost-net/virtioキューをゲストのホットコアから分離しています。NUMAはまた、メモリのローカリティに注意を払う必要があります。トポロジーとチューニングに関するより詳細な背景については、こちらの記事を参照してください：ホスティングにおけるNUMAアーキテクチャ. .高密度のセットアップでは、このカップリングは、より均一で顕著な結果をもたらす。 遅延時間.

コンテナ・オーケストレーション：cpusetポリシーとQoS

コンテナに入れる cpuset.cpus CPUクォータと一致します。Kubernetesは、Requests=Limitsが設定されている場合、CPUマネージャー（「静的」ポリシー）を使用して、Guaranteed QoSクラスのPodに専用コアを提供する。つまり、クリティカルなPodは固定コアに着地し、ベストエフォート型のワークロードは柔軟性を保つ。私はトポロジーを意識してポッドを計画します。NUMAノードごとにレイテンシー経路（イングレス、アプリ、キャッシュ）を分割し、メモリとIRQの負荷がローカルにとどまるようにします。重要なのは 計画性 そうでなければ、測定値はインスタンス間でばらつく。.

Cグループ、公平性、孤立

親和性だけでは保証されない 公平性, だからcgroupsと組み合わせている。cpu.sharesはグループを相対的に優先し、cpu.maxはタイムスライスごとに厳しい上限を設定する。こうすることで、たとえCPUに負荷がかかっていても、うるさい隣人を抑えることができます。マルチテナントホスティングでは、より高いシェアでクリティカルなサービスを保護します。これをまとめると分離過剰なリスクを負うことなく。.

予測可能な待ち時間のためのエネルギーと周波数の管理

パワー状態はジッターに顕著な影響を与える。P99の厳しい目標に対しては、私はホットコアで高い基本周波数を安定させている（ガバナー・パフォーマンスや高電源状態）。 エネルギー性能優先)、ウェイクアップ時間が支配的にならないように深いCステートを制限する。私はターボを適度に使っている。個々のスレッドにはメリットがあるが、熱の制限によって並列動作が発生する可能性がある。 カーン スロットルだ。スループットを均一にするために、私はソケットごとに周波数の上限／下限を設定し、省エネロジックをコールドコアに移動させる。これにより、全体的なスループットを過度に制限することなく、ばらつきを抑えることができる。.

systemd、taskset、Windows：実装

パーマネント・サービスには次のものを使っている。 システムディー RTワークロードにはCPUSchedulingPolicy=fifoと組み合わせている。バックアップがホットキャッシュにスパークしないように、taskset -c 4-7で単発ジョブを開始する。ポッドが固定コアを受け取るように、cpuset.cpusとcgroupv2を使ってコンテナをカプセル化している。Windowsでは、PowerShellでProcessorAffinityをビットマスク16進数に設定する。これらのオプションは、正確な コントロール カーネル限界まで。.

モニタリングとテスト：推測ではなく測定

成功するかどうかは パーフェクト (コンテキストスイッチ、マイグレーション、キャッシュミス)と、時系列ごとのp95/p99を追跡する。wrk、hey、またはsysbenchを使ったワークロード・リプレイは、異常値が小さくなっているかどうかを示す。また、VMのステイル時間やホストコアのIRQ負荷も監視している。ピーク負荷下での短時間のA/B比較により、誤った仮定が明らかになる。数値が一致した場合のみ、私はルールを恒久的なものとして凍結する。 ポリシー にある。

リスク、限界、アンチパターン

剛性ピンニング缶コア 涸れる トラフィックが変動するときにね。そのため、私はクリティカルなスレッドだけを設定し、クリティカルでないスレッドはスケジューラーに残している。オーバーコミットも、ノイジーな2つのVMが同じコアを欲しがるとリソースを食いつぶす。固定しすぎると、後でホットスポットや利用率の低さに悩まされることになる。CPUのピン留めに関するこの記事は、良い現実チェックになる。ほとんど役に立たない明確な目標と結論のある、慎重なアプローチが求められる。指標.

特殊なケース高周波とリアルタイム

サブミリ秒のために私はリンクする 親和性 RTポリシー、IRQチューニング、NUMAの一貫性を持つ。私はネットワークIRQをそれぞれのコアにバインドし、ユーザー空間のスレッドを遠ざけています。チップレットトポロジーのAMD-EPYCでは、コア、メモリコントローラ、NIC間のショートパスを確保している。大きなページ（HugeTLB）はTLBのミス率を減らすのに役立つ。これらのステップにより、分散が大幅に減少し 計画性 HF-Trafficで。.

IRQ制御とI/O分離

Iピン 割り込み要求-パケットフラッドがアプリのスレッドを置き換えないように、専用コアのsmp_affinity経由でハンドラーを使用する。マルチキューNICを複数のコアで共有し、RSSの分布に合わせる。ヘッドオブラインのブロッキングを避けるため、ストレージ割り込みをネットワークIRQから分離している。NGINXの非同期I/Oとスレッドプールは、ホットコアでのシステムコールのブロッキングを防ぎます。このように分離することで、パスを短く保ち ピーク負荷.

段階的導入の手引き

私は次のように始める。 プロファイリング の下にある「Real-Traffic」をクリックし、重要なサービスだけを設定します。それから、さらにスレッドをバインドする前に、p95/p99とマイグレーションをチェックする。Cグループは再起動せずに修正オプションを与えてくれる。ホストごとの変更を文書化し、systemd単位でルールをまとめる。測定値が安定してから構成大雑把に。.

運用、変更管理、ロールバック

私はアフィニティ・ルールをコードのように扱っている。私はsystemdユニットとcgroupポリシーのバージョンを作成し、それらをロールバックする。 舞台上 (最初にカナリア、次にワイド）、明確な帰り道を用意しておくこと。P99のSLOが壊れたり、スループットが低下した場合は、迅速なロールバックが必須だ。私はピーク時の前に変更を凍結し、各ステップの後に移行率、LLCミス率、コアごとの利用率を監視している。こうすることで運用上のリスクを減らし、„良い “個々の最適化がネットワークに望ましくない副作用を発生させるのを防いでいる。.

セキュリティと隔離効果

アフィニティはまた、次のようなことにも役立つ。断熱マルチテナント環境では、クロストークやサイドチャネルを最小限に抑えるため、クライアント間でSMTの兄弟を共有しない。センシティブなサービスは、ノイズの多いIRQソースから切り離された専用コアで実行される。投機的実行のギャップに対するカーネルの緩和策は、コンテキスト・スイッチングのコストを増加させますが、クリーンなピン止めは、タイル境界を横切るスレッドの数が少ないため、その影響を最小限に抑えます。重要：セキュリティ目標と性能目標のバランスをとる。特に保護に値する少数のワークロードに対しては「SMTオフ」が正当化されることがあるが、それ以外のワークロードはSMTスループットの恩恵を受け続ける。.

KPI、SLO、収益性

私はこう定義する 前もって 明確なKPI：p95/p99レイテンシ、スループット、cs/req（リクエストあたりのコンテキストスイッチ）、1秒あたりのマイグレーション、LLCミス率。ターゲット・コリドーは、「p99 -25%、最大スループット≦5%」のようなトレードオフを評価するのに役立ちます。ホストレベルでは、コアのアンバランスとアイドル時間を監視し、ピニングが高価なアイドル時間につながらないようにしています。達成された予測可能性によって SLO ペナルティが軽減されたり、リザーブバッファを小さくできるためクラスタの密度が高まったりする場合、アフィニティは経済的に理にかなっています。この数値的な追跡がなければ、ピニングは直感のままである。 最適化.

レビューと分類

アフィニティは以下を実現する。 サーバー 多くのコアを持つVMでは、わずかな介入で驚くほどの予測可能性が得られることが多い。オーバーコミットやトラフィックの変動が激しいVMでは、デプロイメントをスロットルします。NUMAの認識、IRQのチューニング、公平なクォータが成功を決定する。モニタリングがなければ、ピン止めはすぐに重荷になる。選択的アプローチの勝利 予測可能性 そしてハードウェアを効率的に利用する。.

概要

私はこうしている。 サーバーCPUとの相性, ホットスレッドをデータの近くに維持し、マイグレーションを減らし、レイテンシのスパイクを滑らかにする。ウェブサーバー、PHP-FPM、データベース、VMでは、Cgroups、IRQチューニング、NUMAディシプリンとAffinityを組み合わせています。Systemdオプション、タスクセット、コンテナcpusetsにより、日常的な使用に適した実装になっている。私は、perfと時系列を使った測定で効果を確保し、徐々に制御を変えていきます。ピニングを的を絞った方法で使用すれば、一定の応答時間、クリーンなキャッシュ、そして測定可能なほど高いパフォーマンスが得られる。 スループット.