サーバーと仮想マシン

NUMAノードサーバー：大規模ホスティングシステムにおける重要性

NUMAノード・サーバーは、ソケットごとのメモリ・アクセスをローカルに生成するため、大規模なホスティング・システムの効率を大幅に向上させる。このアーキテクチャがどのように待ち時間を短縮し、スループットを向上させ、それによって ワークロード エンタープライズ・サーバーでより良くスケールする。.

中心点

メモリー・ロケール 待ち時間を短縮し、リモートアクセスを減らす。.
スケーラビリティ メモリバスのボトルネックなしに、多数のコアにまたがる。.
NUMAアウェアネス カーネル、ハイパーバイザー、アプリケーションにスピードをもたらす。.
プランニング ノードあたりのVM/コンテナの数は、スラッシングを防ぐ。.
モニタリング numastat/perf経由でホットスポットを発見。.

NUMAノード・サーバーとは？

私は、各ソケットが独自のローカルメモリ領域を持つアーキテクチャに依存している。 NUMAノード を受け取ります。つまり、コアは主に高速で近くにあるRAMにアクセスし、低速のリモート・メモリを避けることになる。Infinity FabricやUPIのようなインターコネクト経由のアクセスは可能だが、追加時間がかかる。.

UMAとは対照的に、ここではアクセス時間が変化する。 レイテンシー と帯域幅。大規模なシステムでは、メモリバスが破綻することなく、非常に多くのコアを束ねることができる。分かりやすい導入は、コンパクトなホスティングにおけるNUMAアーキテクチャ.

ホスティングにおけるメモリ局所性

プロセスとメモリーを同じノードにバインドすることで、データパスを短くし キャッシュ-ヒットが増加する。このメモリ局所性は、ウェブサーバ、PHP-FPM、そしてデータベースに即座に顕著な影響を与える。リモートアクセスをプッシュバックすることで、1 秒あたりにより多くのリクエストを処理できるようになります。.

CPUとメモリを計画的にバインドすることで、スレッドがノードをまたいだり スラッシング をトリガーします。動的セットアップの場合、私は時間経過とともにアクセスを最適化するNUMAバランシングアプローチをテストします。 NUMAバランシング. .こうすることで、レイテンシを低く保ち、コアをより効率的に利用することができる。.

大規模ホスティングシステムでNUMAが重要な理由

大規模なホスティング・プラットフォームでは、多数のウェブサイトが同時に運用され、以下のような短い応答時間が要求される。 ピーク-トラフィック。NUMAは、データがインターコネクトを経由せずに実行コアの近くにある可能性を高める。これこそが、ショップやAPI、CMSが重要なミリ秒を獲得する場所なのだ。.

こうして、パフォーマンスを犠牲にすることなく、ホスト上でより高い密度を確保することができる。 アップタイム-宛先がより簡単になります。トラフィックのピーク時でも、リモートの負荷が少ないため、応答時間はスムーズなままです。このことは、ユーザー体験の向上とキャンセルの減少という形で直接的に報われます。.

技術の実際

でトポロジーを読んだ。 lscpu そして numactl --ハードウェア への ノード, コアとRAMのレイアウトを明確にした。そして、ワークロードを numactl --cpunodebind そして --メンバインド. .KVMや最新のLinuxカーネルなどのハイパーバイザーは、トポロジーを認識し、すでに有利なスケジュールを組んでいる。.

マルチソケットシステムでは、インターコネクトの帯域幅と、接続するソケットの数に注意を払う。 RAM-ノードあたりのチャンネル数。キャッシュ・フットプリントが大きいアプリケーションはノード・ローカルに配置する。様々なパターンが混在するサービスについては、テストが一貫して有益であれば、インターリーブ・メモリを使用する。.

さらに、私は次のように評価している。 numactl --ハードウェア その ノード距離 オフ：隣接ノード間の値が低いほどリモートアクセスが高速であることを示すが、ローカルRAMに比べてレイテンシは増加する。ただし -mempolicy=preferred。 メモリー・プレッシャー --メンバインド は厳密で、疑わしい場合には割り当てを失敗させる。私は、ワークロードのクリティカリティに応じて、特にこれを使用している。.

プロセスが動的にスレッドを作成する場合は、開始前に次のように設定する。 タスクセット- または 集合-新しいスレッドが適切な場所に自動的に作成されるようにする。 CPU-ドメイン私はデプロイ時にパス全体を計画する：ワーカー、I/Oスレッド、ガベージ・コレクター、バックグラウンド・ジョブには一貫したアフィニティーを与え、ノード間のパスが隠れないようにする。.

主要業績評価指標の比較

レイテンシ、スループットを通じてNUMAの最適化を評価する、, CPU-利用率とスケーリング。各指標は、ローカリティが効果的なのか、リモートアクセスが優勢なのかを示している。負荷をかけた一定のテストにより、次のチューニングステップへの明確な方向性が示されます。.

以下の表は、ウェブ関連サービスとデータベースのホスティングワークロードにおける典型的なサイズを示している。 アクセス リモートアクセスに対して.

指標	NUMA最適化なし	NUMAとメモリの局所性
待ち時間 (ns)	200-500	50～100
スループット（Req/s）	10.000	25.000+
CPU使用率（%）	90	60
スケーラビリティ（コア）	最大64	512+

継続的に測定し、比較する プロフィール 調整前と調整後。ここで重要なのは、効果がランダムに見えないようにするための再現可能なベンチマークである。こうして私は、生産的なオペレーションを行うための具体的で信頼できる指標を導き出すのである。.

p95/p99のようなパーセンタイルは、単なる平均値ではなく、特に意味がある。リモートアクセスを均等化した後、高いパーセンタイルが顕著に低下した場合、プラットフォームは負荷の下でより安定している。私はまた、LLCのミス率、コンテキスト・スイッチ、リモート・アクセスもチェックしている。 実行キューの長さ これは、スケジューリングとキャッシュ効果をきれいに割り当てるためである。.

課題とベストプラクティス

NUMAスラッシングは、スレッドがノードをまたいで常に移動するときに発生します。 メモリ を要求する。私は、固定スレッド配置、一貫したメモリーバインディング、サービスごとの制限でこれに対抗している。明確な割り当ては、目に見えてリモートのトラフィックを減らす。.

テストツールとして、私は次のものを使っている。 ヌマスタット, パーフェクト およびカーネルイベントを ホットスポット を明らかにする。定期的なモニタリングによって、プールが間違ったノードに紛れ込んだり、VMが不利に分散されたりすることがないかがわかります。小さな計画的なステップを踏むことで、私はリスクを最小限に抑え、着実な進歩を確実なものにしている。.

カーネルおよびBIOS/UEFIオプション

サブNUMAクラスタリングやソケットごとのノードパーティショニングなどのBIOS/UEFI設定をチェックします。より細かい分割は局所性を鋭くすることができるが、より厳格なバインディングを必要とする。私は通常、ローカルとリモートのメモリ間の差異を最小化できるように、グローバルメモリインターリーブを無効にする。 メモリ スケジューラーは賢明な判断を下すことができる。.

Linux側では、私は次のようにフィットした。 kernel.numa_balancing（カーネル・ヌマ・バランシング を意識的に使っている。リジッドなHPCやレイテンシーのワークロードの場合、私は自動バランシングを解除する(echo 0 > /proc/sys/kernel/numa_balancing)、混合ワークロードの場合は、明確なCPUアフィニティと組み合わせてテストする。. vm.zone_reclaim_mode ノードが自分のページを積極的に再要求しすぎて、不必要な再要求を引き起こすことがないように、控えめに設定している。.

メモリーを大量に消費するデータベースでは、私は次のように考えている。 巨大ページ ノードあたり透明な巨大ページTHP私は、スタティックなHugePagesを使用し、それらをノードローカルにバインドすることを好む。こうすることでTLBのミスレートを減らし、レイテンシを安定させることができる。また vm.swappiness を0に近づけることで、ホットパスがスワップに終わらないようにする。.

割り込みをトポロジーに合わせる： イラクバランス NIC割り込みが、対応するワーカーが動作しているのと同じノードのCPUで終了するように。ネットワークスタックに RPS/RFS このマスクは、データプレーンでのクロスノードパスを避けるために、ワーカーの位置と一致するように設定しました。.

NVMe SSDの場合は、ノードごとにキューを分散させ、I/Oスレッドをローカルにバインドします。こうすることで、データベース、キャッシュ、ファイルシステムのメタデータは、CPUからRAM、そしてストレージコントローラまで、可能な限り最短のレイテンシチェーンを満たすことができる。永続ログやライトアヘッド・ログの場合は、クリーン・ノードのアフィニティに特に注意を払う。.

共通スタックでの構成

PHPのFPMプールは ノード そして、プール・サイズをコア数に合わせて調整する。NGINXやApacheでは、I/O負荷の高いプロセスをキャッシュと同じ場所にバインドする。PostgreSQLやMySQLなどのデータベースは、ノードごとに固定のHugePagesを受け取る。.

仮想化レベルでは、物理的なレイアウトと一致するvCPUレイアウトを作成します。 レイアウト を使っている。私は特にCPUアフィニティを使っている。 CPUとの親和性. .これにより、ホットパスが不必要にインターコネクトに負担をかけるのを防ぐことができる。.

ワークロードのパターン：ウェブ、キャッシュ、データベース

リスナーソケット、ワーカー、キャッシュが同じNUMAドメインにあれば、ウェブサーバーとPHP-FPMは恩恵を受ける。私はノードごとに独立してスケールします。ノードごとに独立したプロセスグループがあり、それぞれのCPUマスクと共有メモリ領域があります。これにより、セッションキャッシュやOPCache、ローカルのFastCGIパイプがインターコネクトを経由することを防ぎます。.

Redis/Memcachedのセットアップでは、1つの大きなインスタンスを両方のソケットにまたがって使うのではなく、ノードごとに1つずつ、複数のインスタンスを使う。これにより、ハッシュバケットとスラブをローカルに保つことができる。Elasticsearchや同様の検索エンジンの場合、私は意図的にノードにシャードを割り当て、クエリとインジェストのスレッドを、関連するファイルやページキャッシュ領域と同じページに保つようにしている。.

PostgreSQLでは、私は以下を共有している。 shared_buffers とワーカープールを、ノードごとにインスタンスやサービスを分けて、ノードセグメントに分割しています。私は innodb_buffer_pool_instances そして、プールのスレッドがノード内に留まるようにする。チェック・ポインター、WALライター、オートバキュームは、しばしば不要なリモート・アクセスを発生させるので、私は別々に監視している。.

ステートフル・サービスの場合、バックグラウンド・ジョブ（コンパクション、分析、インデックス作成）は、ホット・パスとは時間的にもトポロジー的にも切り離している。必要であれば numactl --preferred, のような完全な厳しさを伴わずに、よりスムーズな荷重移動を可能にする。 --メンバインド を強制する。.

キャパシティ・プランニングとコスト

私は、TDP、RAMチャンネル、希望するRAMチャンネルを計算する。密度ワークロードを移動する前に、ホストあたりノードあたりのRAM比率が高いデュアルソケットは、多くの場合、最高のユーロ・パー・リクエスト値を実現します。ホストが同じレスポンスタイムでより多くのVMを搬送する場合、節約効果が見られます。.

例えば、NUMAを意識した配置に切り替えると、ホスト数が2桁増えることがあります。 パーセンテージ 削減できる。RAMに1ノードあたり数百ユーロの追加コストがかかっても、収支はプラスだ。継続的な運用コスト（ユーロ）に対して測定値を設定すれば、計算はうまくいく。.

LocalityはリクエストあたりのCPU時間を短縮し、消費電力を顕著に削減する。したがって、ワークショップのサイジングでは、ピークreq/sだけでなく、トポロジーごとのkWh/1000リクエストも評価します。このような考え方により、より高密度にするか、ソケットを追加するかの決断がより具体的になります。.

vNUMAとライブマイグレーションの実際

仮想化環境では、物理的な構造に合わせてvNUMAトポロジーをマッピングします。 vNodeごとにVMのvCPUをグループ化し、割り当てられたRAMを含めます。こうすることで、小さいはずのVMが両方のソケットにまたがってリモート・アクセスを発生させることを避けることができる。.

私はQEMUプロセスとそのI/Oスレッドを一貫して固定する。 アイオスレッド そして ボースト-タスクを実行する。メモリ・バックエンドとしてノードごとにHugePagesを保存し、VMが起動するたびに同じローカル・メモリを使用するようにしている。私は意識的に妥協を計画している：非常に厳格なピン留め戦略は、ライブマイグレーションを制限する可能性がある。ここでは、最大限のレイテンシの安定性と運用の柔軟性の間で決める。.

オーバーコミットでは、明確な上限値に注意を払う：ノードあたりのRAMが不足するようになったら、ノードをまたぐような乱暴なスピルオーバーではなく、同じVMグループ内で別の戦略を取ることをお勧めする。データパスが一貫性を保つように、VMワーカーがコンピューティングを行っているノードにvNICとvDiskを接続することを好む。.

NUMAとコンテナ・オーケストレーション

コンテナは、リクエスト、キャッシュ データ はローカルにある。Kubernetesでは、Schedulerが同じノードにコアとメモリを割り当てるように、トポロジー・ヒントを使う。QoSクラスとリクエスト／リミットを確保して、ポッドがあてもなくさまよわないようにしている。.

CPUマネージャーとHugePagesのポリシーをテストしている。 レイテンシー とスループットを向上させる。ステートフルなワークロードは固定ノードを利用し、ステートレスなサービスはエッジに近いところでスケールする。これにより、ローカリティの利点を失うことなく、プラットフォームの俊敏性を保つことができる。.

スタティックCPUマネージャーポリシーで、コアを排他的に割り当て、明確なアフィニティーを得る。トポロジー・マネージャーは シングルヌマノード, ポッドがバンドルされるように。ゲートウェイとイングレス・コントローラーには SO_REUSEPORT-トラフィックがローカルでスケジューリングされるように、ノードごとにリスナーを作成する。私は、キャッシュ、サイドカー、共有メモリーセグメントをポッドグループごとに計画し、それらが同じNUMAノードに着地するようにする。.

ベンチマーキング・プレイブックとモニタリング

私は、NUMA効果を確実に測定し、チューニングするために、決まった手順で作業しています：

トポロジーをキャプチャする： lscpu, numactl --ハードウェア, インターコネクトとRAMチャンネル。.
負荷時のベースライン：ノードごとにp95/p99レイテンシ、Req/s、CPU、LLCミスプロファイルを記録。.
バインディングを導入する： -cpunodebind（クプノデバインド/--メンバインド, ノードあたりのプール。.
再実行：同じ負荷、同じデータで、違いを論理的に割り当てる。.
微調整：割り込みアフィニティ、HugePages、メモリ・アロケータ、ガベージ・コレクション。.
CIにおけるリグレッションチェック：ドリフトを防ぐために、定期的にシナリオを複製する。.

深さについては、以下を参照されたい。 パースタット そして パーレコード バックで、リモートアクセスカウンター、LLCとTLBのミス、カーネルとユーザーランドのタイムシェアを観察する。. ヌマスタット は、各ノードの割り当ての分布とリモートフォールトの発生率を教えてくれる。このビューは、最適化ステップの再現性と優先順位付けを可能にする。.

エラーパターンとトラブルシューティング

典型的なアンチパターンは、不規則なレイテンシーと、それに対応するスループットの向上なしに高いCPU使用率である。よくある原因は、広すぎるCPUマスク、HugePagesを固定しないグローバルTHP、トポロジーを参照しないアグレッシブなオートスケーリング、不運な分散キャッシュである。.

を持つスレッドかどうかをまずチェックする。 ps -eLo pid,psr,psr,cmd そして タスクセット -p その通りに走る。それから ヌマスタット-リモートアクセスのカウンターを作成し、トラフィックのピークと比較する。必要であれば、一時的にインターリーブをオンにしてボトルネックを明らかにし、その後、厳密なローカリティに戻す。.

その価値も証明されている、, a ネジを次々と調整していく：最初にバインディング、次に割り込みアフィニティ、次にHugePages、最後にメモリ・アロケータを微調整する。こうすることで、効果は追跡可能で、可逆的なものになる。.

今後の展開

新しいインターコネクトとCXLにより、アドレス可能な範囲が広がる メモリ となり、非連結RAMがより具体的になります。多数のコアを搭載するARMサーバーもNUMAタイプのトポロジーを利用し、同様にローカリティを重視する必要があります。トレンドは明らかに、より微細な配置戦略へと向かっています。.

私は、スケジューラがNUMAシグナルをより強力に統合することを期待している。 リアルタイム を評価する。ホスティングスタックは、典型的なワークロードに適したバインディングを自動的に統合する。これにより、ローカライゼーションは特別な措置ではなく、標準となる。.

簡単にまとめると

NUMAノードサーバー・バンドル・ローカル リソース ソケットあたりのデータパスを大幅に短縮します。プロセスとメモリを結合し、リモートアクセスを最小限に抑え、一貫して効果を測定しています。その結果、レイテンシー、スループット、密度が顕著に向上しました。.

きれいなトポロジー認識、巧妙なバインディング、そして連続的な モニタリング ホスティング・プロバイダーは、ハードウェアをより有効に活用することができます。このようなステップを踏んでいるプロバイダーは、一貫して高速なサイト、優れたスケーリング、予測可能なコストを実現しています。これこそが、日々のビジネスに違いをもたらすのです。.