サーバーと仮想マシン

サーバーIRQアフィニティとマルチコアネットワークの最適化により、パフォーマンスを最大化

私は以下の方法でサーバーのネットワークパスを最適化している。 IRQアフィニティ また、RX/TXキューをコアにマッピングし、レイテンシ、スループット、p99ジッタを制御します。マルチコアCPUを使用している人は、一貫して割り込み、SoftIRQ、NAPI、NUMAをオーケストレーションすることで、フローがコアアファインを維持し、コンテキストスイッチが削減され、アプリケーションの応答が明らかに速くなります。.

中心点

IRQ分配 どのコアがハードウェア割り込みを行うかを決定し、ホットスポットを防ぐ。.
NUMAの近さ リモートアクセスを減らし、待ち時間のピークを低減する。.
ソフトIRQとNAPI バッチ処理を制御し、コアへの負荷を軽減する。.
RPS/RFS は、フローを消費するスレッドの近くに保つ。.
測定とピン止め は、パフォーマンスをより決定論的にする。.

IRQアフィニティがサーバー運用に重要な理由

高いパケットレートは、すべての割り込みがいくつかのCPUにかかると、個々のコアにすぐに負担がかかる。 ホットスポット キャッシュを避けるためだ。RX/TXキューを適切なコアに割り当てることで、データパスを短く保ち、キャッシュをウォームにしている。これにより、不要なマイグレーションを避け、同じコアで処理ステップを維持するため、p95/p99のレイテンシが短縮される。パケットからアプリケーションワーカーまでの経路が一貫して高速に保たれるように、NIC、メモリチャネル、CPUソケットの物理的な近接性を考慮しています。このコアの親和性により、ハードウェアをすぐにアップグレードしなくても、トラフィックのピーク時に測定可能な安定性が生まれます。.

IRQバランシングと固定アフィニティ

標準サービス イラクバランス 割り込みは自動的に分散されますが、アプリケーションロジック、NUMAターゲット、レイテンシバジェットはわかりません。私は、クリティカルなネットワークIRQを選択したコアにバインドし、ノイズの多い割り込みや重要度の低い割り込みは他のコアに移動させます。このバインディングは、フローごとのパイプラインが一貫性を保つように、アプリケーションプロセスのピン止めと調和します。トラフィックが多い場合は、追加のオーバーヘッドを発生させ、キャッシュ効果を弱める再分配を避ける。より深く掘り下げたい場合は、このガイドで実用的な背景情報を見つけることができる：データセンターにおけるIRQバランシング.

CPUアフィニティ、NUMA、短いデータパス

私は、アプリケーションワーカーとネットワークIRQを同じピン上に置くことを好む。 NUMA-ノードに設定し、メモリアクセスがローカルなままとなるようにしている。NICがノード0にハングアップする場合は、関連するRXキューもそこに設定し、関連するプロセスをこれらのコアにバインドする。こうすることで、高いパケットレートではレイテンシに大きな影響を与える高価なリモートメモリアクセスを回避している。また、ハイパースレッディングペアを組み込むことで、姉妹スレッド同士が干渉しないようにしている。プロセスのピン留め、IRQアフィニティ、NUMAトポロジーのこの三角形は、ネットワーク経路をより予測しやすくし、スループットを向上させます。.

SoftIRQ、NAPI、キュー設計の理解

ハードウェア割り込みの後、カーネルは以下の処理を引き継ぐ。 ソフトIRQ, 多くの場合、IRQを受け取ったコアと同じコアで実行する。負荷が高いときは、SoftIRQの負荷を意識的に分散させて、不必要にデータパスを分断することなくボトルネックを緩和しています。マルチキューNICは、各キューに明確に定義されたコアを割り当てることができるため、真の並列化を達成するのに役立ちます。NAPIを使ってパケットを一括処理することで、割り込みの嵐を起こさず、CPU時間を効率的に活用できる。この記事では、この経路に関する背景知識を提供する： SoftIRQとネットワークスループット.

RPS/RFSとフローの局所性

私は、より広範囲にパッケージを配布するためにRPSを使っている。 RFS フローが消費スレッドで終わるようにする。これにより、キャッシュアクセスが効率的に保たれ、アプリケーションは一貫した応答時間の恩恵を受ける。カーネル・キューがオーバーフローしないように、NICのハッシュ戦略、キューの数、RPSのCPUセットを調和させる。フロー・アフィニティは、APIやマイクロサービスによって生成されるような多くの短いリクエストに対して特に効果的である。このようにして、各フローができるだけ頻繁に同じコアに触れるパイプラインを構築し、不要なマイグレーションを回避する。.

RSS、インダイレクトテーブル、XPS：ハッシュのターゲット制御

ディストリビューションがNICできれいに開始されるように、私は次のように調整した。 RSS (受信側スケーリング）とインダイレクトテーブルを使用して、RXキューが後にアプリのスレッドを処理するコアに正確に割り当てられるようにしている。キューの数が使用するコアの数と一致し、ハッシュ・キーが安定したままであることを確認し、フローが予期せずさまようことがないようにしている。ハッシュ・アルゴリズムが変更されたり、インダイレクト・テーブルが動的に上書きされたりすると、フローの局所性が損なわれ、キャッシュ・ミスが発生しやすくなる。.

TXパス上で、私はさらに以下を有効にした。 エックスピーエス (Transmit Packet Steering) により、送信パケットはアプリケーションを処理するコアから送信されます。これはまた、TXキャッシュをワーカーの近くに保ち、ソケットキューからNICキューへのパスを短く保つためでもある。RXとTXのマッピングは一貫性を保ち、インターフェイスごとに文書化し、再起動してもアーキテクチャがぶれないようにスタートアップスクリプトで定義しています。.

割り込みの合体：スループットとレイテンシの比較

と一緒に合体私はオーバーヘッドを減らすために割り込みをまとめるが、アプリケーションのレイテンシの限界に注意している。ストリーミングやVoIPの場合は、インターバルを短くする傾向がありますが、バルク転送は長いバッチにも耐えることができます。ステップ・バイ・ステップでテストし、p95/p99を測定し、ドロップ、再送、コアごとのCPU使用率をチェックする。その後、ホストとNICごとに設定を書き留めて文書化します。この実践的な記事では、トレードオフについてより深い洞察を提供しています：割り込み合体について.

オフロードとアグリゲーションの適正投与

をセットした。 GRO/LRO CPUオーバーヘッドを削減するために、より大きなバッチを使用する。レイテンシーに敏感なAPIは、GROを控えめにし、LROをオフにした方が反応が良いことが多い。大きなスーパーパケットは、ヘッドオブラインのブロッキング効果を悪化させる可能性があるからだ。バルク転送、レプリケーション、バックアップの場合は、レシーバー側が安定してCPU使用率が下がる限り、GRO/GSO/TSOをより積極的に使用する。.

チェックサムオフロード そして TSO/GSO しかし、ミドルボックスやトンネル、あるいはオフロードの非互換性（特定のカプセル化など）が適切に機能することを確認します。異常が発生した場合は、個々のオフロードを徐々に減らし、スループット、再送、CPU時間への影響を測定します。目標は、全体的に安定し、ピーク時に予測可能なセットを維持することです。.

CPU分離、スケジューラ、エネルギー状態

厳しいレイテンシバジェットのために、私はネットワークパスとアプリワーカー用にコアを分離している。そして CPU分離 と無駄のないハウスキーピング戦略で、システムタスク、Kスレッド、タイマー割り込みが「ホット」コアに入るのを防ぐ。また CPUガバナー を „パフォーマンス “に変え、深さを制限する Cステート, もしこれらがウェイクアップレイテンシーの原因になるのであれば。熱による腐敗は仕上げを台無しにしかねないので、私はコアの温度に目を光らせている。.

の選択である。 授業のスケジューリング は予測可能性に影響する。私はネットワーク関連のスレッドに優先順位をつけているが、積極的かつ排他的に実行することはない。私は、個々のコアでksoftirqdが起動しているかどうかを定期的にチェックしている。これは、SoftIRQの負荷が高すぎるか、不適切に分散されていることを示す明確なサインだ。.

ビジーポーリングと低遅延パス

マイクロ秒をカウントするときは、次のように設定する。 ビジー・ポーリング をターゲットにすることができる。アプリケーションは、選択したソケットに対してポーリングウィンドウを定義し、割り込みを待たずにNAPIバジェットから直接パケットを引き出すことができる。CPU時間の浪費を避けるために短いポーリング間隔を選択し、このテクニックを一定のトラフィックがあるホットパスに限定している。並行して ネット開発予算 システムの他の部分を飢えさせることなく、バッチが十分に大きくなるように、適度に。.

ネットワークのキュー規律とペーシング

をセットアップした。 キューディスク インターフェイスごとに、作業負荷に見合うようにする。私はfq/fq_codelのような最新のディシプリンを使って、バーストをスムーズにし、バッファブロートを避けるために、ペーシングとキューの長さを調整している。マルチキューのセットアップでは、私はこれを ムクプリオ, これにより、トラフィック・クラスは常に正しいHWキューに割り当てられます。また BQL (Byte Queue Limits）をドライバに設定することで、キューが制御不能に増大することがないため、全負荷時の待ち時間が短縮される。.

と交流することが重要である。 エックスピーエス をTXパスに追加した：送信キューを、対応するRXフローも着地するコアにマッピングする。こうすることで、フローの両方向がCPUの近くに留まり、双方向プロトコル（HTTP/2やgRPCなど）でも安定した応答時間を実現できる。.

Linuxでの実践的ワークフロー

負荷の記録から始め、top/htopでCPUの配分をチェックし、/proc/interruptsと/proc/softirqsを見て、ボトルネックを認識するためにethtoolの統計を読み、次の準備をする。 ワークフロー-のステップを踏む。次に、関連するNICキューのIRQ IDを決定し、コアを均等に占有し、NUMAを考慮した適切なCPUマスクを設定する。それから、タスクセットまたはsystemd-CPUAffinityを介して、アプリケーション・ワーカーを、関連するキューも提供する同じコアに固定する。私は、RPS/RFSがフローの局所性を強化する場合にのみRPS/RFSを有効にし、インターフェースごとに一貫したコンフィギュレーションを維持する。最後に、複数のホストに一様に変更を展開する前に、スループット、レイテンシー、ジッターを再度測定する。.

測定、p95/p99と回帰を避ける

私は直感に頼らず、チューニングの前後でレイテンシー、エラー率、コア使用率を測定し、次のことを行っている。 p99 は安定している。また、隠れた副作用を早期に特定するために、SoftIRQタイプごとにコンテキストの変更、移行率、負荷を追跡しています。テストには再現性を持たせ、同じデータセットと固定バージョンを使用し、結果を比較できるようにしています。ピーク時とアイドル時のクロスチェック、および長時間の耐久テストにより、リグレッションを発見します。メトリクス、ログ、アプリケーションのトレースが一致した場合のみ、その構成を新しいベースラインの状態として宣言する。.

仮想化、コンテナ、SR-IOV

仮想化環境では、次のことを確認している。 vCPU, VMのメモリとvNICは、関連する物理NICが終了するのと同じNUMAノードに配置される。可能であれば SR-IOV, データパスが短く、IRQをゲストコアに直接バインドできるように。クリティカルなVMのvCPUを専用のホストコアに固定し、ホストのIRQとゲストのIRQが重ならないようにする。コンテナのセットアップでは膿栓ワーカーコンテナとそのネットワーク IRQ が予測可能な方法で CPU 時間を受け取れるようにする。.

irqbalanceがゲストとホストのどちらをリードすべきかをチェックする。virtioでは、いくつかのキューを設定し、それらをvCPUにきれいにマッピングして並列作業を可能にします。vhost-netが個々のホストコアを利用する場合、私はバックエンドを再分配し、vhostスレッドを物理NICにNUMAに近い状態に保ちます。.

トラブルシューティング：パターンを素早く認識する

コアは飽和、ksoftirqdはアクティブ： RXキュー同士を近づける、キューの数をチェックする、RPS/RFSを調整する、合体を少し増やす。.
P99のジッター： NUMAドリフトをチェックし、C-States/Governorを検証し、オフロードとGROサイズを段階的に調整する。.
再送/ドロップが多い： RX/TXリングサイズ、qdisc、BQLをチェックし、インダイレクトテーブルとXPSの整合性をチェックする。.
不均等なフロー： RSSハッシュとインダイレクトテーブルのバランス、ホットフローピニングの考慮、ハッシュシードの安定。.
VMだけの問題： vhost/virtioバックエンドをNUMAの近くに配置し、SR-IOVを評価し、ホストとゲスト間のIRQをアンバンドルする。.

アプリケーションとデータベースを含む

アプリ・サーバーやデータベースが並行して動作していなければ、きれいなネットワーク・パスはほとんど意味をなさない。 労働者-数、スレッドプール、接続制限を利用可能なコアに合わせる。NGINXやHAProxyのワーカーを適切なコアに固定し、RXキューに合わせる。PHP-FPM、Node.js、Java、Goを、ローカルのNUMAドメインを優先するようにスケーリングし、必要に応じて複数のインスタンスを使用する。RedisやMemcachedなどのキャッシュをCPUの近くに統合し、独自のネットワークとスレッドパラメータに注意を払う。IRQアフィニティ、プロセスのピン留め、アプリのスケーリングの相互作用だけが、レイテンシーとスループットを顕著に向上させる。.

メリットの大きいホスティング・シナリオ

私が主にディープ・チューニングに投資するのは、APIで短いリクエストが大量に発生する場合や、次のような場合だ。 リアルタイム-VoIPやチャットなどの通信には、低いジッター値が必要です。チェックアウトフローはレイテンシーに敏感であるため、ピークロードを伴うEコマースのセットアップが有利になる。高密度のマルチテナントホストでは、キューごとの専用コアが近隣の影響を軽減するため、メリットがあります。また、ストリーミング・サービスでは、新しいハードウェアを購入することなく、1ユーロあたりのスループットを向上させることができる。私が変更を測定可能な状態に保ち、それを正確に展開する限り、コストは計算可能なままです。.

クイック・リファレンス表：コア、キュー、ツール

私は以下を利用しています。 テーブル 新しいホストをセットアップするときや、既存のセットアップを再調整するときの備忘録として。典型的なターゲット、適切な対策、一般的なLinuxツール、レイテンシとスループットに対する意図的な効果を示しています。私はこれを独断的に使うのではなく、実際のトラフィックを使った一連の測定の出発点として使っている。NICアーキテクチャやNUMAトポロジが異なる場合は、コアの選択を変更します。各ホストのドキュメントを保管し、変更を追跡可能にしておくことが重要であることに変わりはありません。.

ゴール	測定	Linuxツール/ロケーション	予想される効果
IRQ負荷の分散	コアにキューをバインドする	/proc/irq/*/smp_affinity	より少ないホットスポット、より一定のレイテンシー
流れの局所性を高める	RPS/RFSのCPUセットを設定する	/sys/class/net//queues//rps_cpus	より少ないマイグレーション、より優れたキャッシュ
バッチ処理の制御	NAPI／コレスティングの微調整	ethtool -C / ドライバのデフォルト	低いオーバーヘッド、制御されたジッター
アプリとIRQのペアリング	ピン工	タスクセット、systemd CPUAffinity	より短いパス、より低いP99
NUMAを避ける	デバイスとコアの共同ローカライズ	numactl、lscpu、lspci -vv	リモートアクセスを減らし、スループットを向上

長期的に有効なベストプラクティス

私はテストラウンドごとにコントロールレバーを1つだけ変更し、メトリクスを文書化し、結果を保存する。 ドキュメンテーション をホストのレポに追加しました。キューとコアのマッピングを明確に記述し、レプリケーションにスクリプトを使用することで、コンフィギュレーションの一貫性を保っています。ドロップ、再送、タイムアウトのログを監視し、それらをカーネルメトリクスと相関させます。シャドーボトルネックが残らないように、ハイパーバイザーとストレージのレベルも分析に含めます。テストが悪影響を示したり、ワークロードが変化したりした場合に備えて、ロールバックを準備しています。.

簡単にまとめると

私は割り込みを使うことで、最大のネットワーク性能を達成している、, キュー とワーカーを制御し、フローごとのデータパスを安定させる。IRQアフィニティはハードウェアの負荷を適切に分散し、SoftIRQ、NAPI、RPS/RFSは処理を効率化します。NUMAプロキシミティは、回避可能なメモリ回り込みから保護し、ジッタを低減します。再現可能な測定による段階的なチューニングは、設定ミスを防ぎ、真の進歩を示します。これらのビルディング・ブロックを一緒に考えれば、レイテンシが重要なサービスに最新のマルチコア・サーバーの能力を自信を持って活用することができます。.