サーバーと仮想マシン

大規模データベースサーバー向けのNUMAメモリポリシー：パフォーマンスを的確に最適化

NUMAメモリ 大規模なデータベースサーバーにおいては、スレッドが必要なメモリからどの程度近い位置で動作するか、またレイテンシが応答時間やスループットにどの程度影響するかが決定的となります。私はCPUの割り当て、メモリの配置、およびワークロードの規模を的確に調整し、遠隔からのアクセスを削減することで、信頼性が高く、計画可能な パフォーマンス.

中心点

トポロジー 理解する：ノード、コア、RAM、および相互接続を的確に考慮する。.
ポリシー ワークロードの目的に応じて、「Strict」、「Preferred」、「Interleave」から適切なものを選択してください。.
親和性 実装：スレッド、IRQ、およびメモリをローカルにバインドする。.
仮想マシン ノード単位で：vCPUとRAMを1つのNUMAノードに配置する。.
モニタリング 実施内容：リモートリード、P99レイテンシ、ノード負荷の測定。.

NUMAトポロジーの理解

私はどの最適化も、まず トポロジー: NUMAノードがいくつ存在するか、コアがどのように分散されているか、RAMがソケットにどのように接続されているか、そしてインターコネクトへのアクセスにどれほどのコストがかかるか。ローカルメモリへのアクセスは、ノード境界を越えたアクセスよりもはるかに時間がかからないため、私は不必要な リモート-方法。大規模なデータベースサーバーでは、スレッドとデータが同じノード内に留まるようにワークロードを計画することで、パフォーマンスが向上します。アクティブなデータ量が1つのノードに収まらない場合は、デフォルトの挙動に任せるのではなく、意図的に分散を計画します。そうすることで、 レイテンシー 低く抑えられており、高負荷時でも安定した処理能力を確保します。.

BIOSおよびハードウェアの設定を適切に選択する

BIOSで、以下のことを確認します。 ノードインターリービング NUMA分離を維持するために無効にしています。メモリチャネルはソケットごとに均等に割り当て、クロックや帯域幅が不必要に低下しないよう、構成（1DPC 対 2DPC）に注意を払っています。以下のような機能は Cステート また、レイテンシの目標値については、コアが頻繁にスリープ状態から復帰する必要がないよう、省電力モードの設定を控えめにしています。. SMT/ハイパースレッディング 私はワークロードごとに評価を行っています。メモリ依存度の高いOLTPワークロードの場合、キャッシュへの負荷と変動を低減するため、コアごとの並列にアクティブなSMTスレッド数を制限しています。また、各ソケットごとにPCIeデバイス（NIC、NVMe）がローカルに接続されていることを確認し、それらの IRQ また、DMAパスがインターコネクトを横断しないようにする。この点を徹底して構築することで、ポリシーやアフィニティが効果を発揮するための基盤が築かれる。.

メモリポリシーを適切に選択する

の選択である。方針カーネルがどのノードからメモリを割り当てるか、およびフォールバックの仕様を制御します。「Strict」は厳格な制限を設定し、対象ノードに空きがない場合は割り当てを中止します。これにより、優先順位が パフォーマンス 柔軟性について。「Preferred」は優先ノードを維持するが、リソースが不足した場合には他のノードに切り替わるため、中庸の選択肢となる。 Interleaveは、ラウンドロビン方式でページを複数のノードに分散させるもので、非常に大規模で利用率が均一なデータの場合に有効です。多くのデータベースでは、PreferredやStrictを用いたローカル戦略の方が、通常はより適しています。 チョイス.

方針	行動	代表的な使用例	メリット	リスク
厳しい	ターゲットノードからのみストレージを取得し、それ以外の場合はエラーとなる	潜在臨界データベース明確なノード計画に基づき	可能な限りローカルなアクセス, 予測可能なレイテンシ	ノードが満杯の場合、割り当てが失敗することがあります
優先	優先ノード。他のノードへのフォールバックも可能	一般的なワークロード変動負荷下で	適度な柔軟性を保ちつつ、良好な近接性を確保	供給不足時のリモート勤務比率の増加
インターリーブ	複数のノードにわたるラウンドロビン	非常に大規模で、幅広く利用されているデータ	複数のノードへの負荷分散	通信環境が劣悪な場所では、遅延が長くなる可能性がある

スレッド、CPUアフィニティ、およびメモリバインディング

ターゲットノードのコアにスレッドをピン留めし、numactl を使ってメモリをバインドし、IRQ を次のように調整して、 データ ローカルに留める。CPUアフィニティとメモリバインディングを組み合わせることで、コストのかかるリモート読み取りを削減し、実行時間のばらつきを小さくします。きめ細かな制御を行うため、プロセスレベルまたはスレッドレベルのポリシーを活用し、バッファプールをアクティブなワーカースレッドに可能な限り近づけています。さらに深く掘り下げたい方は、以下の実践的な手順を参照してください。 CPUとの親和性, 、これらは本番環境のホストに直接適用できます。これにより、一貫性を確保しています 遅延時間 システムに高い負荷がかかっている場合でも。.

地域のホットセットを優先する

私は、以下のホットセットを特定します。 ワークロード そして、それらを厳密にローカルに配置し、一方、使用頻度の低いデータは比較的柔軟に配置しても構いません。この優先順位付けにより、コアパスについてはノードのRAMに近い位置に維持できます。負荷が増加しても、コストの高いパスは引き続きローカルで実行されるため、ソリューションはスムーズにスケーリングします。この順序付けがない場合、スレッドがノード間でアクセスする頻度が高まると、レイテンシ曲線は急激に悪化してしまいます。明確な装丁まさにこの動作を確実に防止します。.

ストレージNUMAとネットワークNUMAの統合

私は組織する NIC そして NVMe-デバイスをソケットに的を絞って割り当て、そのIRQをローカルコアに誘導します。受信／送信ステアリング（RSS/RPS/XPS）については、各ノード内で一貫性を保つようにしており、これにより、データベーススレッドが実行されている場所でパケットが処理されるようにしています。 NVMeでは、コアごとに複数のキューを使用し、IOスレッドをローカルに固定することで、ログパスやデータパスがインターコネクトを往復しないようにしています。レプリケーションについては、ノードごとにネットワークパスを分離し、受信するWAL/Redoストリームがローカルに到達するようにしています。これにより、 入出力– かつ CPU パスが一致しており、データベースはメモリシステム全体にわたる不要なコピーにサイクルを浪費することはない。.

ノード単位でのVMの計画

私は、vCPUの数とRAMが1つの物理NUMAノードに収まるようにVMのサイズを設定しています。そうすることで、 レイテンシー およびインターコネクトトラフィック。ノードよりも大きいワイドVMは、必然的にメモリアクセスを分散させるため、予測可能性が失われます。VMを大きくする必要がある場合は、vNUMAを明示的に計画し、ノード間で対称的な割り当てになるよう注意を払います。ホスト側については、レイテンシを重視するワークロードではオーバーサブスクリプションを避け、VMごとにローカルメモリを確保するようにしています。物理ノード構造の概要については、「„NUMAノードの計画“「これにより、VMのサイズに関する決定が容易になり、 エラー 配置時のトラブルを未然に防ぎます。.

ハイパーバイザーの設定に注意してください

ハイパーバイザーがvNUMAをどのように表現しているかを確認し、vCPUグループと物理コア一貫性を保ちます。さらに、スケジューラがローカルに留まれるよう、VMのNUMAトポロジーがホストのそれと一致するようにしています。メモリ予約やアンチアフィニティルールについては、必要最小限に抑えつつ、必要な厳格さは確保しています。 1ソケット上のVM密度を高めるよりも、ノードに近い場所にVMを分散させることを優先しています。このようにして、 リモート-アクセス回数を最小限に抑え、I/Oパスを安定させてください。.

コンテナとオーケストレーションの実践

コンテナに入れる cpuset-境界の一貫性：CPUおよび関連するメモリマスク（cpuset.cpus, cpuset.mems) は密接に関連しています。Systemd-Slices と Units には固定の CPU アフィニティが割り当てられ、これによりカーネルがメモリ優先順位を確実に適用できるようになっています。オーケストレーション層では、Pods/Services を計画しています ノードの近く, 、ワークロードがノード間を行き来しないように、トポロジー評価と静的なCPU割り当てを活用しています。Huge PagesはPod/コンテナごとに明示的に宣言し、ノードごとのサイズと数を一定に保っています。重要：インフラストラクチャおよび補助プロセス（ロギング、サイドカー、バックアップ）は、データベースのホットセットに干渉しないよう、別のコア、あるいは場合によっては反対側のNUMAノードに割り当てています。.

NUMAバランシングとOSのチューニング

自動NUMAバランス調整は、ローカルな アクセス ワークロードが移動したり、フェーズが大きく変化したりする場合にパフォーマンスを向上させます。私はこれを意図的に活用していますが、ページを頻繁に行き来させることで、メリットよりもデメリットの方が大きくなっていないか注意深く観察しています。明確な関連性を持つ固定化されたプロセスでは、絶え間ない再配置よりも、手動で設定したポリシーの方が効果的な場合が多い。カーネルパラメータ、IRQ制御、透過的なHuge Pagesについては、それぞれデータベースやプラットフォームの文脈に合わせて検証している。その際、以下の内容が参考になる。 NUMAバランシング-設定を段階的にテストし、散乱レイテンシを低減すること。.

Huge Pagesを効果的に活用する

TLBミスを減らし、大規模な メモリ各領域をより効率的に処理するためです。データベースサーバーについては、事前にページを予約し、ノードに割り当て、インスタンスが実際にそれらを使用しているかどうかを確認します。レイテンシ目標がある場合は、Transparent Huge Pages を無効にし、静的 Huge Pages を設定して、割り当てが確定的な状態を維持するようにしています。しかし、NUMAノードへの近接性は依然として決定的な要素です。Huge Pagesは優れた戦略を強化するものではありますが、それに取って代わるものではありません。これを無視しても、ほとんどメリットは得られません。 パフォーマンス また、ページングの際に副作用が生じるリスクがある。.

データベースのサイジング：バッファプールと処理量

アクティブなワークロードは、バッファプール、ロックキャッシュ、プランキャッシュ、および最もアクセス頻度の高い表 1つのノードに収まるようにします。インスタンスが非常に大規模な場合は、すべてのノードにまたがる巨大なモノリシックなインスタンスを構築するのではなく、ノードごとにサービスやシャードを分割します。 OLTPの場合、ノードごとのバッファプールをコンパクトに保ち、ローカルヒット率を優先します。OLAPスキャンについては、データ量が膨大で均一であるような特殊なケースでは、インターリーブが有効な場合があります。このルールを守らないと、 相互接続-電力需要がピークに達するまさにそのタイミングで、送電網に負荷がかかり、予備電力を消費してしまう。.

データベース特有のコツ

エンジンのプロセスおよびスレッドモデルを考慮に入れています： PostgreSQL プロセスを利用しているため、メインインスタンス、Autovacuum、Checkpointerをノードごとに分けて設定し、 shared_buffers シャードごとにローカルで。 MySQL/InnoDB 私は整理する バッファプールインスタンス ノード上で、IOスレッドとログライターをローカルに配置する。. SQLサーバー 最適化されたソフトNUMAと、物理ノードに沿ってスケジューラやメモリグループを配置する割り当て方式の恩恵を受けています。. オラクル-インスタンスはローカルのLarge Pagesを使用して構築し、ワーカーサーバーとI/Oサーバーをノードごとに分割しています。一般的に、NUMAを意識したアリーナを用いてアロケーター（例：jemalloc）のアリーナ競合を低減し、 ロックマネージャー ノードに沿ってパーティショニングとシャーディングを行うことで、ラッチのホットスポットを局所的な範囲に留める。.

モニタリング：重要な指標

リモートリード、ノード間トラフィック、ノードあたりのページフォールト、およびP99を測定しています。レイテンシー 関連するクエリについて。さらに、ノードごとのCPU使用率、NUMAミス率、およびローカルメモリアクセスの割合も監視しています。この視点により、ポリシーが機能しているか、あるいはスレッドが制御不能にリモートページにアクセスしているかがわかります。ピーク値を、スケジューラの決定、マイグレーションイベント、および割り当てエラーと照合します。これらのメトリクスによって初めて、方針実験室だけでなく、本番システムにおいても永続的に機能する。.

テスト戦略と展開

段階的にテストを行っています。まずは、～に関するマイクロベンチマークから 帯域幅 そしてノードごとのレイテンシ、さらにコールドキャッシュとウォームキャッシュを含む現実的なワークロードを検証します。負荷レベルを段階的に引き上げ、P95/P99/P99.9を測定し、平均値だけでなく分布も観察します。変更点（ポリシー、アフィニティ、Huge Pages、IRQルーティング）をすべて記録し、同一の条件下でA/Bテストを行います。本番環境への展開に先立ち、以下を定義します。 キャンセル基準 また、回帰が発生した際に迅速に以前の設定に戻せるよう、ロールバック計画も用意しています。定常負荷下での短時間のソークテストにより、 ドリフト そして、短期間では目に見えない移住現象も生じている。.

手順ごとの進め方

まず、私は トポロジー: ノード数、コア割り当て、メモリチャネル、およびインターコネクト。その後、ノードごとの目標ワークロードを決定し、ホットセットがそこに収まるかどうかを確認します。次のステップでは、プロセスまたはスレッドレベルでCPUアフィニティ、IRQルーティング、およびメモリバインディングを設定します。その後、ワークロードの動的な変化に応じてNUMAバランシングを有効または無効にし、必要に応じてノードごとにHuge Pagesを予約します。最後に、再現性のある負荷テストで結果を検証し、監視を行います。 主な数字 連続運転中.

実践例と課題

短いトランザクションが多数発生するOLTPインスタンスでは、ワーカースレッドとバッファプールを1つの ノード を指定し、「Strict」または「Preferred」に設定します。広範囲なスキャンを行うデータウェアハウスでは、データの利用状況が非常に均一で、ノードの稼働率が良好な場合、インターリーブの恩恵を受けることができます。 VMは、ノードの境界を越えて拡大し、ハイパーバイザーがメモリをオフセット割り当てを行うようになると、計画性が著しく低下します。1つの「広範囲な」VMがインターコネクトに過負荷をかけ、その結果、隣接するVMの速度も低下させるケースを頻繁に目にします。これらの影響は、ローカルな アロケーション そして、正しいvNUMA構成に戻ります。.

エラーシナリオとアンチパターン

と一緒に 厳しい 割り当てが失敗し、OOMキラーが作動するリスクが高まります。そのため、ターゲットノードには余裕を確保し、失敗を監視するとともに、フォールバック策（例：ピーク時間帯を外したタイミングでの的を絞ったリサイズ）を定義しています。Transparent Huge Pagesを常に-モードがレイテンシパスで引き起こす デフラグ そしてStalls――私は静的な予約を利用するか、THPを有効にしています マドヴァイズ. 自動NUMAバランス調整機能は、負荷が変動している際にページを行き来させることがあります。ページバウンスのパターンが確認された場合は、ポリシーを手動で再設定します。VM内では バルーン また、メモリ圧縮は予測可能性の妨げとなるため、重要なデータベースではこれらの機能を無効にしています。ノード間のライブマイグレーションについては、ダウンタイム枠を確保して実施するか、あるいはまずデータベース側でデータを移行し、インターコネクトが二次的に混雑するのを防ぐようにしています。.

生産能力計画と成長

ノードごとに1つずつ リザーブ 負荷のピーク時、Autovacuum／Compaction、および定期的なメンテナンスジョブ用に、10～20の%を設定しています。データ量が増加した場合は、バッファプール全体を無闇に拡大するのではなく、まずノード（シャード／サービス）単位でスケールアップを行います。ノードごとの厳格な上限値を設定し、ローカルヒット率が低下したりリモート比率が上昇したりした時点でアラートを発することで、知らぬ間に進行する「静かな増加」を抑制しています。今後数四半期の予測においては、データ量だけでなく、 取引率 また、アクセス分布の変化も考慮されます。なぜなら、これらは純粋なメモリ要件の変化よりも速いペースでホットセットを移動させることが多いからです。これにより、プラットフォームの安定性が保たれ、NUMAの局所性を損なうことなく、拡張が制御された形で行われます。.

ショートバランスシート

私は、以下の方法を用いて大規模なデータベースサーバーの最適化を行っています。 NUMA-トポロジー、ポリシー、ワークロードの規模を適切に統合する。ローカルなメモリ割り当ては決定的なミリ秒単位のパフォーマンス向上をもたらす一方で、予期せぬリモートアクセスはP99レイテンシを肥大化させる。今後は、VMをノード内に収まるように、あるいはvNUMAを明確に活用できるように計画する。 OS設定、アフィニティ、Huge Pagesは目的を明確にして活用し、その効果を検証した上で、測定データを基にのみ変更を展開します。これらの手順を確実に実行すれば、期待通りの パフォーマンス 最新のハードウェアを採用しており、高負荷下でもプラットフォームを安定して高速に稼働させます。.