サーバーと仮想マシン

LinuxのNUMA統計を正しく分析する

Linux NUMA 統計データからは、各プロセスがローカルメモリをどの程度効率的に保持しているか、またリモートアクセスによってレイテンシが増加している箇所がどこなのかがわかります。ここでは、これらの数値を目的意識を持って読み解き、経時的な傾向を評価し、そこから明確なチューニング手順を導き出す方法について説明します。 パフォーマンス 導き出される。.

中心点

メーターの仕組みを理解する: numa_hit、numa_miss、numa_foreign、local_node、other_node、interleave_hit
文脈を評価する: 負荷プロファイル、トポロジー、ワークロードの種類
トレンドを測定する: 前後比較と間隔について
プロセスの確認: システム全体 vs. プロセスごと
チューニングを適用する: アフィニティ、ポリシー、配置

NUMA統計が実際に示していること

私はNUMAの数値を、次のような地図として捉えています。 保管場所 およびデータ経路。高い numa_hit これは、割り当てが目的のノードに到達したことを意味します。一方、numa_miss は、カーネルが別のノードにフォールバックせざるを得なかったことを示しています。カウンター numa_foreign は、ターゲットノード上の対応する値を表示し、全体像を補完します。 local_node と other_node を使用することで、アクセスがローカルにとどまったのか、それともリモートメモリを利用したのかを判別できます。.

これらの数値は、決して単独で解釈してはならない。なぜなら、 ワークロード 反応は大きく異なります。短い処理は、全体的なパフォーマンスに目立った変化をもたらすことなく、散発的にミス（ミスヒット）を発生させます。一方、インターリーブポリシーは意図的に分散した割り当てを行い、これによりinterleave_hitが増加します。そのため、私は常に意図されたポリシーと現在の負荷を確認しています。その上で初めて、その値が対応を必要とするものなのか、それとも設計に合致しているのかを判断します。.

私にとっての核心となる考え方は次の通りです： カウンター これらは「判断」ではなく「シグナル」を提供するものです。私は個々の数値ではなく、時間軸にわたるパターンを探しています。そうすることで、システムへの変更によって局所性が変化するかどうかを把握できるのです。このトレンドの全体像が把握できて初めて、プロセスを移動させるか、ポリシーを調整するか、あるいはCPUバインディングを設定するかを判断します。したがって、すべてのNUMA分析は、明確な問いと再現可能な測定ポイントから始まります。.

核計数器を文脈に合わせて解釈する

私はいつも比較してしまう numa_hit そして、絶対値そのものを評価するのではなく、numa_miss と numa_miss を組み合わせて分析します。ミスが増加している場合は、潜在的なターゲットノードにおける numa_foreign の推移を並行して確認します。両者が一致する場合、それは純粋な読み出しによるアーティファクトではなく、真の負荷シフトを示しています。local_nodeとother_nodeは、実際のアクセス状況を通じてこの全体像を補完します。これにより、割り当てはローカルで開始されたものの、その後の処理でより遠方のメモリから読み出されていたかどうかを判断できます。.

1つの高い other_node ワークロードが意図的に分散されていても、私は気になりません。一方、多くのワーカーを持つWebサーバーは、一貫したロカリティの恩恵を受けます。そのため、私は全体像だけでなく、個々のプロセスにも目を向けています。個々のサービスが通常とは異なる挙動を見せ始めたら、すぐにその配置を見直します。システム全体で不具合が増加して初めて、トポロジーや負荷に関する原因を探ります。.

経時的な比較：実用的な測定手順

私は、ある期間の開始時と終了時にメーターの読み取り値を測定します。 最終段階 そして、その差を算出します。個々の値は影響を曖昧にしますが、差は変化を示します。たとえば30秒から60秒といった間隔で繰り返し測定すれば、多くの場合、傾向を把握するのに十分です。デプロイ、カーネルの更新、またはハードウェアの変更後は、同じ間隔で再度比較を行います。その際にミスが多くなったり、local_nodeがずれたりした場合は、実際の変化が生じていることになります。.

このような時系列データは、以下の範囲をカバーしています 配置ミス スナップショットよりも迅速に把握できます。私はこれらの線を、CPU使用率、コンテキスト切り替え、ノードごとのメモリ使用量と関連付けて分析しています。これにより、ノードのRAMにおけるボトルネックが回避行動を引き起こしているかどうか、あるいは新しいプロセスがノードの状態を崩しているかどうかを確認できます。ヒットとミスの単純な比率については、常に推移として示し、単一の数値としては提示しません。.

システム全体を確認し、その後プロセスを詳細に確認する

まずは全体像から始めます ヌマスタット その後に個々のプロセスを確認します。この順序なら、多くの影響が全体として把握できるため、時間を節約できます。プロセスビューでは、プロセス固有の出力を活用して、目立つサービスを特定します。候補が特定でき次第、私は プレースメント CPUおよびメモリの割り当てについて。これに関する実用的なヒントは、以下の記事にまとめられています。 CPUおよびメモリのアフィニティ.

特にJavaサービス、PHP-FPM、あるいはデータベースの場合、多くの場合、きちんと整理された 親和性, 、ミスを大幅に減らすためです。コンテナオーケストレーションは、NUMAを意識しないスケジューラがリソースを分散させるため、こうした問題を隠しがちです。そのため、私はポッドやVMごとのノード割り当てを細かく管理しています。CPUセットとRAMの割り当てが一致すると、local_nodeの値が明らかに上昇します。必要なデータセットの近くでプロセスが実行されるようになると、一部の問題は自然に解消されます。.

NUMAカウンタの概要（表）

新しいシステムを評価する際、以下の表を作成して、各項目を キーパーソン すぐに分類します。そこには、その重要度、典型的な解釈、および考えられる対策が示されています。私はこれを厳格な枠組みとしてではなく、チェックリストとして捉えています。重要なのは、負荷プロファイルやサーバーのトポロジーとの照合です。この文脈を踏まえて初めて、適切な判断を下すことができます。.

カウンター	意味	解釈	アプローチ
numa_hit	指定ノードでの割り当て	数値が高いのは良いこと	順位を維持
numa_miss	割り当てが他のノードに振り替えられた	レイテンシが発生するリスクの高まり	アフィニティ／ポリシーの確認
numa_foreign	このノードにおける外部割り当て	numa_missの対となるもの	宛先ノードを分析する
local_node	ローカルストレージへのアクセス	高ければ安い	RAMに近づくプロセス
other_node	リモートストレージへのアクセス	意図がないとはいえ、やはり懸念される	トポロジー／負荷の確認
interleave_hit	インターリーブ割り当てでのヒット	Interleave‑Policy で予想される動作	均一性を評価する

これによって概要介入するタイミングをより迅速に判断します。説明のつかない変化がないにもかかわらず numa_miss が増加した場合は、原因分析を開始します。 interleave_hit の値が高いままの場合は、ポリシーが意図した通りに有効になっているかを確認します。other_node の値が負荷の増加なしに上昇している場合は、競合するワークロードを調査します。このようにして、このテーブルは的を絞った対策の出発点となります。.

NUMAトポロジーの理解と活用

チューニングを行う前に、私は トポロジー サーバーの構成要素：ソケット、コア、メモリチャネル、レイテンシパス。あるプロセスがソケット0で実行されているにもかかわらず、そのワークセットがソケット1にある場合、アクセス時間が長くなります。これによりスループットが低下し、応答時間が不安定になります。特にメモリを大量に消費するサービスは、不要な長距離アクセスに敏感に反応します。そのため、私はデータ集約型のプロセスを、十分な空きRAMを持つノードに配置するようにしています。.

非対称な接続ノードが使用するチャネル数が少ない場合など、その影響はさらに大きくなります。そのような場合、私はプロセスを分散させるのではなく、キャッシュされたデータセットを意図的に移動させます。VMおよびコンテナのホストは、各インスタンスが一貫したノードバインディングを取得するように設定しています。これにより、クォータを制限することなく、リモートデータ転送量を削減しています。マシンの物理的制約がガイドラインとなり、私はそれに従っています。.

インターリーブとバランシングを正しく理解する

インターリーブ・ポリシーは、意図的にメモリをノード間で分散させることで、 スループット プロセスごとに増加するか、ホットスポットが減少する。この構成では、高い interleave_hit が望ましいとみなされる。その際、私は絶対的な局所性ではなく、主に均一性を確認する。AutoNUMA や NUMA バランシングは役立つ場合もあるが、あらゆる状況で有効というわけではない。.

状況に応じて、自動で バランシング アクティブな状態を維持します。一貫性があり、長時間稼働するサービスの場合は、固定バインディングを設定することが多いです。負荷が変動する場合は、AutoNUMAが適切に対応できます。その利点とリスクについてよくまとめられている記事があります NUMAのバランス調整. 目標と枠組みが明確になって初めて、適切なモードを選択します。.

ワークロードのパターン：データベース、VM、Webサービス

データベースは以下に対して敏感に反応します レイテンシー CPUとRAMの間です。そのため、インスタンス、バッファキャッシュ、アクティブなシャードはすべて同じノード上に配置しています。仮想マシンは、ゲストOSが一貫したパスを見られるよう、明確なCPUセットとノードRAMを活用することでメリットを得られます。多数のワーカーを持つWebサービスは、ワーカーグループが1つのノードにバインドされたままの場合に真価を発揮します。ストレージ戦略については、ケースに応じて適切な NUMAメモリポリシー.

一方、分析系の仕事や大規模なスキャン作業については、一部は 分配された 。この場合、インターリーブはハードロカリティよりも優れた帯域幅を実現することが多い。重要なのは、ワークロードのI/Oパターンをありのままに捉えることだ。書き込みは読み取りとは異なり、ランダムアクセスはシーケンシャルアクセスとは異なる。私は、教科書上では聞こえが良さそうなポリシーではなく、アクセスパターンに合致するポリシーを選択する。.

実用的な測定手順とツール

始めるには、これだけで十分です ヌマスタット そしてプロセスビューです。私はメーターの読み取り値を、日付、PID、負荷インジケーターと共に記録しています。この際、同一の時間枠で測定を行うことが重要です。そうすることで、変更前後の差異を明確に把握することができます。本番稼働期間中は、その差分を記録し、リリース時期との相関関係を分析します。.

目立つ場合は サービス さらに、lscpu、numactl、perfなどのツールを使用して、CPUバインディングやノードビュー、およびリモート負荷を確認します。測定のたびに、選択したポリシーを記録しています。変更後は再度測定を行います。トレンドラインが安定して推移して初めて、その効果を成功と評価します。やみくもに切り替えると、見かけ上の改善に陥りやすいからです。.

よくある誤解を避ける

高い interleave_hit インターリーブが意図的に有効になっている場合、これはエラーではありません。同様に、実行時間が長い場合、単発のミスは無視できる程度です。私は常に、ピーク値だけでなく、その区間全体にわたる密度と分布を確認しています。一部の人々は「other_node」を全面的に否定的なものと解釈し、ワークロードの特性を 간과しがちです。そのため、私はまず設計目標を確認し、その上で数値を評価するようにしています。.

もう一つの誤解： 全体像 よし、これで問題なし。多くの場合、外れ値は一部のPIDにのみ隠れているものだ。あるいは、コンテナスケジューラが、ローカルグループとしてまとめる方が理にかなっているにもかかわらず、ポッドをノード全体に分散させてしまうこともある。こうした現象は、プロセスごとに測定して初めて気づくものだ。このレベルの詳細な分析なしでは、分析は中途半端なままになってしまう。.

効果のあるチューニングの手順

私は次のように始める。 プレースメント: データが存在するか、あるいは存在すべきノード上のプロセス。次に、スレッドがソケットをまたいで移動しないように、CPUアフィニティを設定します。続いてメモリバインディングを行い、カーネルが指定された場所にメモリを割り当てるようにします。変動する負荷に対しては、ポリシーを確認し、適切であればAutoNUMAを適用します。.

その後、私が以下のことを行います 一貫性 ライフサイクルにおいて：再起動、デプロイ、スケーリングによって、ノードへの参照が不意に変更されてはならない。再現性を確保するため、バインディングをコードとして文書化する。その後、再度測定を行い、変化量を評価して、微調整を行うかどうかを判断する。あらゆる変更には、明確な測定結果による裏付けが必要である。.

実例：失敗作からヒット作へ

仮に、ある データベース 負荷がかかると、numa_miss が増加し、other_node も上昇する。クエリのレイテンシの変動が激しくなる。まずプロセスの割り当てを確認したところ、ロールアウト後にサービスはノード A で実行されているものの、キャッシュはノード B に割り当てられていたことが判明した。ノードBにCPUとメモリを固定して割り当てると、状況が一変しました。numa_hitが増加し、ミスは減少しました。応答時間はより安定し、リモートアクセスがなくなったため、CPU負荷もわずかに低下しました。.

並行して、私は方針. インターリーブが意図せず有効になっており、割り当てが分散されていました。優先ノードへの切り替え後、キャッシュはローカルに閉じられたままとなっています。1時間の測定結果から、デルタ値が改善を確認しています。その時点で初めて、このチューニングを成功とみなします。この検証がなければ、その瞬間の状況だけで判断していたら、誤った判断を下していたでしょう。.

実務における指標と目安

意思決定の際には、信頼性の高い オッズ 個々の生データではなく。各プロセスごとに、割り当て率 local_alloc = numa_hit / (numa_hit + numa_miss) を算出します。さらに、 アクセス率 local_access = local_node / (local_node + other_node) を算出します。これら2つの値を合わせることで、メモリが割り当て後もローカルで使用され続けているかどうかがわかります。私にとっての大まかな目安は次の通りです。レイテンシが重要なサービスの場合、リモートアクセスを5～10 %未満に抑えることを目標としています。分析的な帯域幅ワークロードの場合、スループットが向上する限り、20～30 %までは許容しています。決定的なのは、 安定性 長期的に見て。負荷がかかっている状態でも安定して維持される数値の方が、完璧な数値が一時的にピークに達するよりも好ましい。後日の測定結果を明確に位置づけられるよう、サービスごとにこれらの目標範囲を記録している。.

Cgroups、コンテナ、およびスケジューラの落とし穴

コンテナ環境では、まず cpuset‑割り当て：CPUセットおよび cpuset.mems は同じノード領域をマッピングする必要があります。そうしないと、必然的にミスが発生します。私は、固定のCPUリクエストを持つPodが複数のNUMAノードにまたがらないようにし、スケジューラが同じアプリケーションのワーカーをまたがって分散させないようにしています。バースト型の場合、1つのノード内に収まるように、Podごとの最大スレッド数を制限しています。私は以下の内容を文書化しています。 NUMAドメイン デプロイメントごとに、一貫性のあるレプリカを要求します（ノードごとに1つのワーカーグループとし、2つのノードにまたがる半グループは認めません）。 Podごとのストレージ容量をギリギリに計算してしまうと、意図しない負荷がかかってしまいます。ノードごとにわずかな余裕を持たせておくことで、カーネルが早期に他のノードへフェイルオーバーすることを防げます。コンテナが頻繁に再起動される場合は、決定論的なバインディングに注意を払い、 コールドスタート 偶然ではなく、条件の悪い場所を割り当てられたわけではない。.

仮想マシンとvNUMAの一貫性を確保する

VMに関しては、私の注目は vNUMA: 仮想トポロジーは物理トポロジーと一致している必要があります。各vNUMAノードが、正確に1つの物理NUMAノードに割り当てられるようにvCPUを分割します。ホスト側では、QEMU/ハイパーバイザーのスレッドをこのドメインにピン留めし、割り当てられたRAMが完全にこのノードから提供されるようにします。. バルーン また、レイテンシが重要なVMについては、オーバーコミットを慎重に許容しています。過度なバルーニングは、ホットセットをノードから追い出し、リモートアクセスを急増させる恐れがあるからです。ライブマイグレーションでは、移動後にアサインメントを再度確認します。環境によっては、この過程で細かく設定されたCPUおよびメモリアサインメントが失われることがあるからです。vNUMAのアラインメントが適切に整ってから初めて、システム全体でnumastatを評価します。そうしなければ、原因ではなく症状だけを修正することになってしまいます。.

THP、Hugepages、およびページ移行

透明な巨大なページ (THP) は、役立つこともあれば、障害となることもあります。ページサイズを大きくすると、TLBミスが減り、帯域幅が向上しますが、カーネルがHugepagesを遅れて 崩壊した または移行された場合、不適切な 遠距離 生まれる。私は2つのルールを守っている。第一に、その方針明確に定義し（例：優先ノード）、可能な限り最初からローカルに大規模な割り当てを行う。第二に、固定された大規模なキャッシュを持つワークロードの場合、可能であれば静的なHugepages（hugetlb）を設定し、これを特定のノード上で明示的に予約する。これにより、断片化や、それを補うためのリソースの移動が軽減されます。時系列データを確認し、長時間の実行後に other_node―の割合が増加している場合、私は以下の点を確認する。 ページの移行 圧縮が行われているかどうか、またTHPの設定がパターンに合っているかどうかを確認します。私にとって重要なのは、グローバルに無効化したり有効化したりしないことです。サービスごとに判断し、局所性やレイテンシへの影響を測定します。.

「Reclaim」、「Swap」、「Memory Pressure」を正しく読み解く

ミスが発生しても順位に明らかな変化が見られない場合、私は以下を探します。 ストレージの圧力 ノードごとに。フルノードになると、カーネルはリクレイムとコンパクションを余儀なくされますが、その一部は kswapd 別のノード上で――これにより、カウンタに副作用が生じます。ノードごとに空きメモリとページキャッシュの使用率を確認しています。有効化された スワップ ホットセットを追い出し、レイテンシを急増させる恐れがあります。特に影響を受けやすいサービスについては、スワップを無効にするか、厳格に制限しています。ログやperfビューで、負荷のピーク時にリクレイム・ピークが発生していないか確認します。目標は、十分な空き領域を確保し、, 地域の 割り当てがずれないように、ターゲットノード上のRAMを確保しておく。そのためにキャッシュを縮小する必要がある場合は、汎用ページキャッシュよりも、そのサービスのワーキングセットを優先する。.

実用的なコマンドと評価

プロセスビューには、以下のものを利用しています numastat -p そして、次のように補足する cat /proc//numa_maps, 、領域ごと（匿名、ファイルベース）およびノードごとの割り当てを確認するには。. numactl --ハードウェア 遅延行列とノードサイズを返します。, lscpu --extended ノードへのCPU割り当てを表示します。リモートパスに重点を置いたメモリアクセスを行う場合、私は次のように設定します。 perf mem 負荷パターンを検証するために使用します。デルタ値は再現性を持って収集しており、例えば：

測定ルーチン

t0: numastat（全体）および numastat -p を使用して上位の PID を保存する
30～60秒間負荷走行、同一のワークロードフェーズ
t1: numastat を再読み込みし、カウンタごとのデルタ値を計算する
CPU、コンテキスト切り替え、およびノードのメモリ値のログを並行して記録する

その後、私は オッズ そして、システム全体の傾向から著しく逸脱しているプロセスを特定します。不確実性が残る場合は、測定を少なくとも3回繰り返します。一貫性のある変動値のみを信頼できるものと判断します。継続的なモニタリングのため、カウンタを時系列データにマッピングし、リリース・メタデータと関連付けます。これにより、 回帰点 すぐに

体系的なNUMAチューニングのためのチェックリスト

目標の定義：レイテンシ対スループット、固定負荷対可変負荷
トポロジーの把握：ノード、レイテンシ、ノードごとの空きRAM容量
ベースラインの測定：numastatの総計およびプロセスごとの数値を測定し、比率を算出する
配置の修正：CPUアフィニティ、メモリバインディング、ポリシー
コンテナ／VMの調整：cpuset.cpus = ノード、cpuset.mems を適切に設定；vNUMA を正確にマッピング
THP/Hugepagesを慎重に選択し、断片化に注意を払う
メモリ負荷の軽減：ノードごとのヘッドルーム、スワップ戦略の確認
事後測定：デルタ値を比較し、経時的な安定性を確保する
ドキュメント化：コードとしてのバインディング、NUMAコンテキストを含むリリースノート

簡単にまとめると

私は、以下の方法を用いてNUMAの数値を解析しています。信号関連して参照：カウンターペア、時間経過、プロセスビュー。キー値である numa_hit、numa_miss、numa_foreign、local_node、other_node、interleave_hit からは、局所性、回避動作、分散戦略が読み取れます。私は、固定された閾値ではなく、トポロジーとワークロードに基づいて判断を下します。チューニングは、配置、アフィニティ、適切なポリシー、そして正確な測定ルーチンから始まります。そうすることで、安定した パフォーマンス, 、CPUとRAMがアプリケーションに適しており、長距離通信もめったに発生しないためです。.