VM パフォーマンス Day3 – メモリ最適化と HugePages / TLB / NUMA の考え方

VM のメモリ最適化は、メモリ容量を増やすことだけではありません。重要なのは、CPU がどのメモリへ、どのページサイズで、どの NUMA ノードを経由してアクセスするかです。

仮想化環境では、ゲスト OS とホスト側のメモリ管理が重なります。そのため、ページテーブル、TLB、HugePages、NUMA ローカリティ、メモリ予約、バルーニングが VM の性能に影響します。

Day3 では、HugePages / TLB / NUMA を中心に、VM のメモリ性能をどう設計するかを整理します。

メモリ最適化で見るべきもの

メモリ性能は、容量、帯域、レイテンシ、ページ管理、NUMA 配置の組み合わせで決まります。VM ではこれに仮想化レイヤが加わるため、物理サーバーよりもメモリアクセス経路を意識する必要があります。

観点	見る内容	問題が出る例
ページサイズ	4KB / 2MB / 1GB のどれで扱うか	ページ数が多すぎて TLB ミスが増える
TLB	仮想アドレスから物理アドレスへの変換キャッシュ	TLB ミスでページウォークが増える
HugePages	大きなページでメモリを扱うか	予約不足や断片化で確保できない
NUMA	CPU とメモリが同じ NUMA ノードにあるか	NUMA 越えでレイテンシが増える
バルーニング	メモリを動的に回収するか	性能保証 VM でメモリが揺れる

HugePages はページ管理を大きくする技術

通常の Linux では、メモリは主に 4KB ページで管理されます。VM が大きなメモリを持つ場合、4KB ページの数は非常に多くなり、ページテーブルや TLB の負担が増えます。

HugePages は、2MB や 1GB のような大きなページでメモリを扱うことで、ページ数を減らす仕組みです。ページ数が減ると、アドレス変換の管理コストが下がり、TLB の効率も上がります。

• ページ数を減らす
• TLB ミスを減らしやすくする
• ページウォークの頻度を下げる
• 大容量メモリ VM の管理コストを下げる
• DPDK や NFV のようなメモリ集約型処理と相性がよい

ただし、HugePages は入れれば必ず劇的に速くなるものではありません。効果はワークロード、メモリアクセスパターン、NUMA 配置、ページサイズ、予約方法によって変わります。

2MB HugePages と 1GB HugePages の違い

HugePages には主に 2MB と 1GB の選択肢があります。どちらもページ数を減らす目的は同じですが、運用上の扱いやすさは大きく違います。

ページサイズ	特徴	向く用途
2MB HugePages	扱いやすく、多くの環境で現実的に使いやすい	一般的な高性能 VM、DB、アプリケーションサーバー
1GB HugePages	TLB 効率は高いが、事前予約や確保失敗のリスクが大きい	NFV、DPDK、メモリ集約型 VM、低遅延用途

1GB HugePages は強力ですが、空きメモリが断片化していると確保できないことがあります。そのため、起動時予約や NUMA ノード単位の設計が重要になります。

TLB を理解すると HugePages の意味が見える

TLB は Translation Lookaside Buffer の略で、仮想アドレスから物理アドレスへの変換結果を保持する CPU 内部のキャッシュです。CPU はメモリへアクセスするたびにアドレス変換を行うため、この変換が速いかどうかは性能に影響します。

TLB に変換結果があれば速くアクセスできますが、TLB にない場合はページテーブルをたどる必要があります。これが TLB ミスです。ページ数が多いほど、TLB がカバーできる範囲は狭くなり、TLB ミスが増えやすくなります。

• 4KB ページは細かく管理できるがページ数が多い
• 2MB / 1GB ページはページ数を減らせる
• ページ数が減ると TLB がカバーできるメモリ範囲が広がる
• TLB ミスが減るとページウォークのコストが下がる

NUMA メモリ配置を CPU ピニングと合わせる

Day2 で扱った CPU ピニングは、メモリ配置とセットで考える必要があります。vCPU を特定 NUMA ノードの CPU に固定しても、VM のメモリが別 NUMA ノードに確保されると、CPU はリモートメモリへアクセスすることになります。

この状態では、CPU は速くてもメモリアクセスが遅くなります。特にメモリアクセスが多い VM、DB、NFV、DPDK、ストレージ処理では NUMA 越えが大きな差になります。

• vCPU とメモリを同じ NUMA ノードへ寄せる
• HugePages も NUMA ノード単位で予約する
• SR-IOV や NVMe passthrough は PCIe デバイスの NUMA ノードも確認する
• VM サイズが NUMA ノードを超える場合は、分割や設計変更を検討する

バルーニングは性能保証 VM では慎重に扱う

メモリバルーニングは、ホスト側が VM からメモリを回収し、メモリ利用効率を高めるための仕組みです。一般的な統合基盤では有効ですが、性能を保証したい VM では慎重に扱う必要があります。

性能保証 VM では、メモリが常に安定して確保されていることが重要です。バルーニングにより VM の有効メモリが変動すると、キャッシュ、ページ配置、アプリケーションの挙動が揺れる可能性があります。

• 汎用 VM ではメモリ効率化に有効
• 高性能 VM ではメモリ予約を優先する
• HugePages とバルーニングは相性が悪い場合がある
• 性能測定環境ではメモリ状態を固定する

メモリ最適化は予約と運用の問題でもある

HugePages や NUMA 固定は、性能を安定させる一方で、運用制約を生みます。特に 1GB HugePages や NUMA ノード単位のメモリ固定は、VM の起動、移動、メンテナンス、障害時復旧に影響します。

設定	得られるもの	失うもの
HugePages	ページ管理と TLB 効率の改善	柔軟なメモリ割り当て
1GB HugePages	大容量メモリ VM の効率	確保のしやすさ、移動性
NUMA 固定	ローカルメモリアクセス	配置自由度
メモリ予約	性能の安定性	ホスト集約率
バルーニング無効化	メモリ状態の安定	メモリ効率化

設計時の確認ポイント

VM のメモリ最適化では、次の観点を確認すると整理しやすくなります。

• その VM はメモリ容量ではなくメモリアクセス性能が問題になっているか
• CPU ピニングと同じ NUMA ノードにメモリを配置できているか
• HugePages は 2MB で十分か、1GB が必要か
• HugePages は起動時に予約する必要があるか
• メモリバルーニングを許容できる VM か
• 性能改善と引き換えに、配置自由度の低下を許容できるか

まとめ

VM のメモリ最適化は、メモリ容量を増やすことではなく、CPU が効率よくメモリへアクセスできるようにする設計です。HugePages、TLB、NUMA、メモリ予約、バルーニングを分けて考える必要があります。

HugePages はページ数を減らし、TLB 効率を改善するための技術です。ただし、効果はワークロードと配置設計に依存します。特に NUMA を無視すると、HugePages を使っても性能が安定しません。

高性能 VM では、CPU ピニング、HugePages、NUMA メモリ配置、I/O デバイスの NUMA を一体で設計することが重要です。Day4 では、ストレージ I/O の経路と仮想ディスクの性能特性を整理します。

VM パフォーマンスシリーズ

• VM パフォーマンス最適化 – NUMA / CPU / I/O / ネットワークの設計ハブ
• VM パフォーマンス Day1 – VM の性能ボトルネックとは何か
• VM パフォーマンス Day2 – CPU 最適化と NUMA / CPU ピニングの考え方
• VM パフォーマンス Day4 – ストレージ I/O 最適化と virtio / raw / qcow2 の考え方
• VM パフォーマンス Day5 – virtio-net の構造と仮想 NIC の性能特性
• VM パフォーマンス Day6 – vhost-net / vhost-user と kernel bypass の考え方
• VM パフォーマンス Day7 – SR-IOV / PCI Passthrough による仮想化の迂回
• VM パフォーマンス Day8 – DPDK による高速 dataplane と NFV の基本

関連記事

• CPU ピニングを外した瞬間、それはもう別のサービスである
• VyOS VPP 導入検討 – 実運用ルーターに VPP をそのまま適用する難しさ
• パブリッククラウド上で NFV 型 NF は成立するのか – アンダーレイ / オーバーレイ / 帯域制約で考える