サーバーと仮想マシン

LinuxにおけるNUMAバランシング：無効にするか、有効のままにするか？

LinuxにおけるNUMAバランシングは、 カーネル メモリアクセスを自動的に最適化するのか、それとも配置を自分で意図的に制御するのか。このガイドでは、いつ「numa balancing」を有効にしておくべきか、またいつそれを レイテンシー- セキュリティを無効にする。.

中心点

自動 NUMAチューニングを行わなくても、混合ワークロードに対応できます。.
無効化 ピニング、静的ポリシー、またはハードレイテンシの場合。.
オーバーヘッド スキャン、障害、および移行によって発生します。.
構成 sysctl またはブートパラメータで制御します。.
テスト 推測するのではなく、測定してから判断する。.

NUMAの簡単な解説：レイテンシと局所性

NUMAシステムでは、ハードウェアがメモリを複数のノードに割り当て、個々の CPU 地理的に近い。ローカルなアクセスは遠隔のアクセスよりも時間がかからない。これはすぐに レイテンシー 帯域幅の影響も感じられます。あるノードでプロセスが実行されているのに、データが別のノードにある場合、アクセスごとに貴重なマイクロ秒を失ってしまいます。まさにこの時点でカーネルが働き、場所ページ数。基本的な考え方を理解していれば、すぐに分かるでしょう。演算コアとデータの近接性こそが、一定の パフォーマンス.

自動NUMAバランス調整の仕組み

カーネルは、どのコアからプロセスがページにアクセスしているかを監視し、それに応じて ヒント-Faultsを無効にします。これにより、どのノードへのアクセスが集中しているかを検知し、それに応じて該当するページをそのノードに移動させます。こうした移行により、遠隔地からのアクセスが削減され、ローカルでの ヒット率. 特に、スレッドが移動したりメモリが移動したりするような動的なワークロードにおいて、その効果を実感しています。さらに詳しく知りたい方は、CPUとメモリの近接性との関係について、 CPU／メモリのアフィニティ実践的に理解する。.

いつアクティブにしておくべきか：代表的なワークロード

アプリケーションに独自のNUMAロジックがなく、プロセスが頻繁に変更. 典型的な例としては、アプリケーションサーバー、負荷が変動するデータベース、および多数の コンテナ. このような構成では、手動で固定しなくても、自動機能によってページとスレッドがより密接に連携するようになります。特にマルチソケットホストでは、ローカルからのアクセスの割合が顕著に増加します。多様なサービスを提供する管理者にとっては、これは有益な妥協時間と労力。.

無効にするタイミング：明確な基準

意識的にピンときたり、はっきりわかったりした瞬間、自動モードをオフにします ポリシー 設定します。numactl、cgroups、あるいはMPOL_BIND/MPOL_PREFERREDを使用する場合、メモリパスについてはすでに確定した決定がなされています。その場合、ヒントフォールトやマイグレーションによって不要な オーバーヘッド. 。これは、1マイクロ秒単位の速さが重要であり、予測可能性が最優先されるリアルタイムやHFTのシナリオにおいても同様です。注文配置ルールの選定についてさらに深く掘り下げる場合は、適切なメモリポリシー.

オーバーヘッドの理解と測定

自動バランス調整には手間がかかる：スキャン、, 障害また、ページ遷移はCPU時間を消費します。リモートアクセスが大幅に減少している場合はほとんど目立ちませんが、すでにレイアウトがローカルにある場合には、その手間をかける価値はほとんどありません。そのため、私は常にnumastatやperf、そして意味のある ベンチマーク. 重要なのは、数分単位での推移であり、単なる一時的なピークだけではありません。測定値が、ローカルアクセスが増加し、レイテンシが低下していることを一貫して示して初めて、そのモードを維持します。.

設定：Sysctl とブートパラメータ

ステータスは /proc または Sysctl で確認し、必要に応じて、 リスタート. テストには、以下のようにコンソールで実行する簡単なコマンドで十分です。再起動後も設定が維持されるよう、普段は sysctl ファイルに値を設定しています。起動時に設定したい場合は、カーネルパラメータ `numa_balancing=enable` を使用するか、 無効にする. 変更点ごとに記録し、どのワークロードフェーズでその変更を行ったかを書き留めています。.

cat /proc/sys/kernel/numa_balancing
echo 0 > /proc/sys/kernel/numa_balancing
sysctl -w kernel.numa_balancing=1
# /etc/sysctl.d/90-numa.conf
# kernel.numa_balancing = 0

コンテナおよび仮想化のシナリオ

VMやコンテナが多数存在するホストでは、自動 ローカリゼーション その強みを存分に発揮します。プロセスの起動や終了、Cgroupによる負荷の分散が行われ、カーネルはアクティブなコアに近い場所にメモリを保持します。私は特に、複数の ノード. 個々のインスタンスを厳密にピン留めする特殊なケースについては、明確に区別し、その部分で自動的に処理される機能を意図的に無効にしています。より詳細な分類については、実際の事例を参照すると参考になります。 NUMA最適化ホスト運用時。.

実務のための判断表

以下の概要では、典型的なシナリオ、予想される効果、そして私の明確な推薦. 私はこれを出発点として利用していますが、実際のシステム上の測定値で置き換えることは決してありません。どの環境にも固有の特性があり、再現可能な結果が得られてから初めて判断を下すようにしています。結果確実です。体系的に進めれば、後でトラブルシューティングやチューニングにかかる時間を節約できます。本番展開の前に小規模なテストを実行することは、ほぼ常に コンスタンス および計画性の欠如。.

シナリオ	代表的な効果	私のおすすめ
NUMAチューニングを行っていない標準ワークロード	ローカルからのアクセスが増え、遠隔からのアクセスが減った読み物	アクティブのままにする
負荷が変動するデータベース	動的なページローカライゼーション、中程度スキャン	有効にしたまま、テストする
ハードリアルタイム、あるいはHFT	ヒントフォールトのレイテンシが問題となるジッター-目標	無効にする、手動でピン留めする
numactl/cgroups による手動のピンニング	自動運転車が固定物と衝突したポリシー	無効化
静的メモリポリシー（MPOL_BIND など）	移住は真のメリット	無効化
テスト／分析環境	その場所の全体像がよく把握でき、効果	有効なままにし、バリエーションを確認する

試験およびバリデーションに関するガイドライン

バランサーを有効にした状態で開始し、ローカルとリモートの動作を記録する アクセス numastat について。その後、この機能を無効にして、まったく同じ条件で測定を繰り返します。差異の評価は、平均値だけでなく、 パーセンタイル. 生産環境の負荷プロファイルを用いた回帰テストが、最も信頼性の高い結果をもたらします。その上で初めて、ホスト、VM、あるいは特定の サービス.

よくある落とし穴と誤解

「オートマチックがすべてに取って代わる」というのは、よくある誤解だ。 ピン留め. それは間違いです。なぜなら、固定されたレイテンシー予算では、追加のフォルトをほとんど許容できないからです。また、「移行は常に」という前提も同様に誤りです。無償起こり得る。特に、もともとローカルなレイアウトの場合、オーバーヘッドはプラスよりもマイナスに作用することが多い。通説に惑わされず、正確に測定すれば、はるかに高い精度で意思決定を行うことができる。精度.

自動化の限界と相互作用

AutoNUMAは、プロセス自身が割り当てた匿名ページに対して大きな効果を発揮します。しかし、すべてを適切に移行できるわけではありません。ピン留めされたページ（mlock）、DMA／デバイスメモリ、DAX、またはRDMA登録領域は、元の位置に残ります。また、共有ページ（例えば、頻繁にアクセスされるライブラリやページキャッシュなど）についても、複数のプロセスが競合してアクセスするため、マイグレーションによるメリットは限定的です。 アクセスパターン 生成する。また、以下のコストも考慮に入れる。 透明な巨大なページ (THP)：その移動には4-KiBページの場合よりもコストがかかり、負荷の急増を引き起こす可能性があります。厳しいレイテンシ目標を追求する場合、予期せぬ事態を防ぐために、THP=never または madvise を、バランス調整を無効化し、クリーンなピンニングと組み合わせて使用することがよくあります。.

もう一つの側面は、CPUスケジューラとの相互作用です。スケジューラは、スレッドをそのデータが格納されている場所に配置しようとしますが、バランサーはデータをスレッドが実行されている場所に移動させます。両者は互いに補完し合っていますが、負荷が不安定な場合には一時的に振動引き起こす。実際には、スキャン間隔によってこうした影響は緩和される。負荷プロファイルの変動が極めて激しい場合は、スキャン期間を長くするか、より安定したスレッドピンニングを行うことで状況を緩和できる。.

スキャンパラメータの微調整

グローバルスイッチのほかに、自動機能の積極性を微調整するためのカーネルパラメータが存在します。正確な名称はカーネルのバージョンによって多少異なる場合がありますが、その目的は変わりません：

kernel.numa_balancing_scan_delay_ms: start、fork、またはexecの実行後、最初のスキャンが開始されるまでの待機時間。.
kernel.numa_balancing_scan_period_min_ms / _max_ms: プロセスアドレス領域ごとのスキャン周期の下限および上限。.
kernel.numa_balancing_rate_limit_mb: メモリ帯域幅を節約するために、ページ移動に対する時間枠ごとの上限値。.
kernel.numa_balancing_scan_size_mb: 1回のスキャンパスごとにマークされるメモリ量（利用可能な場合）。.

レイテンシが重要な設定では、自動機能を即座に無効にするのではなく、慎重を期して最小・最大周期を延長し、レート制限を引き下げるようにしています。これにより、多くの場合、適切なバランスが得られます。つまり、ヒントフォルトやマイグレーションは減少する一方で、実際の配置ミスに対しては十分な対応が可能になります。.

# の例（一時的、再起動まで有効）
sysctl -w kernel.numa_balancing_scan_period_min_ms=60000
sysctl -w kernel.numa_balancing_scan_period_max_ms=240000
sysctl -w kernel.numa_balancing_rate_limit_mb=64

メトリクスと詳細な診断

確かな判断を下すために、メカニズムを直接可視化する指標を確認しています。私が定期的に参照している情報源は3つあります：

numastat: システム全体およびプロセスごとのローカルアクセスとリモートアクセスの比率。.
/proc//numa_maps: プロセスごとのメモリページのノードごとの分布。active、file、anon などのフラグも含まれる。.
/proc/vmstat：numa_hint_faults、numa_hint_faults_local、numa_pages_migrated などのカウンタは、バランサーが動作しているかどうか、またそれが成功を持っています。

# プロセスごとの概要
numastat -p 

# 詳細表示：どの領域がどこにあるか？
grep -E 'anon|file' /proc//numa_maps | head

# カーネル全体での AutoNUMA アクティビティの確認
grep -E 'numa_(hint_faults|pages_migrated)' /proc/vmstat

結果から傾向を探ります。ローカルからのアクセス比率は着実に上昇しているか？同時にヒントフォルトは減少しているか？そうであれば、そのレイアウトは定着していると言えます。多くの移行が行われたにもかかわらずローカルアクセスの割合が横ばいのままなら、むしろサイクルを無駄に消費してしまうことになる。レイテンシの目標値については、応答時間の95パーセンタイルおよび99パーセンタイルも追加で確認する。平均値のわずかな改善は、 ジッター 覆い隠される。.

ワークロードプロファイル：一般的に有効なケース

実務を通じて、AutoNUMAが一般的に役立つ場合とそうでない場合に関するパターンが明らかになってきました：

JVMサービスとアプリケーションサーバー：厳格なスレッドピンニング戦略や、独自の積極的なNUMAロジックが有効になっていない限り、多くの場合、これらの機能から恩恵を受けることができます。一部ランタイムにはNUMAオプションが用意されていますが、これらを厳格に適用する場合は、自動処理を制限するか、無効にします。.
リレーショナルデータベース：負荷が変動し、キャッシュが混在している場合、自動調整機能は多くの場合うまく機能します。しかし、専用のピニング（ワーカーからノードへ、共有バッファを厳密に分散）を設定する場合は、再現性を確実にするためにバランス調整機能を無効にします。.
インメモリストアとキャッシュ：大規模で頻繁にアクセスされるワークセットは、ローカルに配置することでメリットが得られます。インスタンスがシングルスレッドで動作している場合や、厳密にピン留めされている場合は、機能を無効化することで不要なマイグレーションを防ぎます。.
HPC/MPIおよび科学計算コード：ほとんどの場合、明確な配置およびバインディングのルール（OpenMP/numactl）が存在します。ここでは、自動化よりも予測可能性が重要であるため、NUMAバランシングは無効にしています。.

仮想化：vNUMA、ピンニング、ライブマイグレーション

ホストとゲストの相互作用において、私は以下の両方の側面を考慮しています：

ゲスト内のvNUMAトポロジーがホストの物理NUMAトポロジーと一致している場合、ゲストバランサーは適切な判断を下すことができます。これと異なる場合、「誤った近隣関係」が生じますが、AutoNUMAによる補正には限界があります。.
vCPUをホストCPUに固定し、ゲストメモリを特定のノードにバインドする場合、これは明示的なポリシーとなります。重複したマイグレーションを防ぐため、このVMレベルでAutoNUMAを削減または無効にします。.
ライブ移行の後、ウォームアップ期間が見られます。新しい均衡が確立されるまで、ヒントフォールトが増加します。この期間中は、以下のためのバッファを計画しています。 レイテンシー-の先端を。.

インスタンスの起動・停止が頻繁に行われ、Cgroupによって負荷が移動する高密度な仮想化ホストでは、ホスト側の自動制御機能が多くの場合、実質的なメリットとなります。一方、「Noisy Neighbor」の影響を受けやすい専用VMについては、リソースを適切にカプセル化し、ルールを静的に設定しています。.

実用的な目標値と許容基準

延々と微調整し続けることがないように、まず「良い」とはどういう意味かを定義しておきます：

一般的なサービス：分散が小さい場合、70～85%のローカルアクセスで十分な場合が多い。.
レイテンシSLA：目標はローカルで90%以上、ヒントフォールト率には明確な上限を設定し、99パーセンタイルを安定して維持する。.
帯域幅に負荷がかかる場合：移行処理によってメモリチャネルが飽和しないように、レート制限や処理期間を適切に調整してください。.

私はこれらの閾値を記録し、複数の負荷段階にわたるA/Bテストを分析しています。結果が再現可能になって初めて、判断を下します。.

トラブルシューティングチェックリスト

突発的なレイテンシの急上昇：THPの移行と「numa_hint_faults」のピーク値との間に相関があるかどうかを確認する。対策：スキャン間隔を長くし、THPを「madvise/never」に設定し、必要に応じて「Balance」を無効にする。.
有効化してもほとんど効果がない：スレッドが強くピン留めされているか、あるいは固定のメモリポリシーが設定されているのでしょうか？その場合、自動処理が設定と衝突してしまいます。.
移行ペースが速いにもかかわらず、リモートアクセスが多数発生している場合：レート制限を確認して引き上げるか、あるいは処理レートを安定させる（スレッドの固定、キャッシュの温存状態を維持）。.
不明確な測定値：システム全体の値だけでなく、numastat -p および /proc//numa_maps を使用して、プロセスごとの視点から確認してください。.

見落とされがちな細かい点

ページキャッシュに依存するワークロード：AutoNUMAは主に匿名ページに効果を発揮します。主にI/Oに制約される作業を行う場合は、バランス調整によって劇的な改善は期待すべきではありません。.
cgroups と cpusets：cpuset.mems は、グループがアクセスできるノードを制限します。これは、自動処理が動作する範囲を厳格に定める枠組みです。.
メモリのホットプラグ／ノードのオフライン化：動的なトポロジーにより距離が変化します。変更後は、再度テストを実行し、必要に応じてスキャンパラメータを調整することをお勧めします。.

簡単にまとめると

一般的なサーバーのワークロードについては、手作業を必要とせずにほぼ最適な状態を保てるため、自動設定をオンにしています。 データ アクティブなコアを起動させます。リアルタイム処理、HFT、手動によるピンニング、または固定ポリシーが適用される場合は、オーバーヘッドやジッターを避けるためにこれらを無効にします。テスト段階では、測定、判断、再実行という反復的な作業を行います。検証. 設定はシンプルに保ち、変更点はすべて記録し、信頼できる指標を用いてその効果を確認しています。そうすることで、NUMAハードウェアの強みを最大限に活かしつつ、不必要な リスク 対応する。.