Huge PagesはホームラボのVMに測定可能なパフォーマンス向上をもたらすのか？

ヒュージページは一部のホームラボVMで測定可能な利点をもたらしますが、仮想化を高速化する万能スイッチではありません。特に有力な候補は、データベース、インメモリサービス、パケット処理アプライアンス、ページテーブルのオーバーヘッドが問題になるほど高負荷を維持するVMなど、大容量メモリを使用しTLBの影響を受けやすいワークロードです。負荷の低いHome Assistant VM、小規模なLinuxユーティリティVM、または時々しか使わないテストマシンでは、RAMを予約するほどの差が出ない可能性があります。

実用上のルールは、常時利用に切り替える前に、通常のメモリを使った同じVMとヒュージページを使った同じVMをベンチマークすることです。LinuxにはすでにTransparent Huge Pages（THP）があり、KVM/libvirtでは明示的なHugeTLBページでゲストをバックアップすることもできます。静的ヒュージページは、ホストの柔軟性と引き換えに、より予測可能な大規模ページによるバックアップを実現します。そのため、RAMに余裕がないホームサーバーや、積極的なオーバーコミットを行う環境では、得られる効果より失うもののほうが大きくなる可能性があります。

ヒュージページはアドレス変換の処理を減らすものであり、VMのあらゆるボトルネックを解消するものではありません

ほとんどのx86 Linuxシステムでは4 KiBのベースページが使われますが、2 MiBや1 GiBなどの大きなページサイズを使うと、1回の変換でより多くのメモリをマッピングできます。LinuxカーネルのTransparent Hugepageドキュメントでは、その中心的な利点を説明しています。大きなマッピングによりTLBミスを減らすことができ、ネストされたページテーブルを使う仮想化環境では、TLBミスの処理コストも低くなる可能性があります。

カーネルには、HugeTLBページガイドで明示的なHugeTLB予約についても記載されています。このガイドでは、透過的な昇格だけに頼らず、予測可能なページサイズを使いたい場合に利用する、予約済みの大規模ページ機構について説明しています。

これは、アドレス変換がワークロードに占める割合が大きい場合にのみ重要です。ヒュージページは遅いディスクを高速化したり、ネットワーク帯域幅を増やしたり、CPU競合を解消したり、ゲストRAMの不足を補ったりするものではありません。VMがほとんどの時間をストレージ、リモートAPI、または単一スレッドのアプリケーションの待機に費やしている場合、ホストのページサイズを変更しても結果はほとんど変わらない可能性があります。

どのホームラボ VM が最も恩恵を受けやすいか？

VM のアクティブなメモリセットが増え、ホットな状態を保つほど、Huge Pages の有力な候補になります。大規模なバッファプールを持つデータベース、インメモリキャッシュ、分析エンジン、高スループットの仮想ルーター、一部のゲームやビルドのワークロードでは、十分な量のメモリに繰り返しアクセスするため、変換エントリが少なくなることが有効です。Red Hat の KVM ガイダンスでも、仮想化チューニングのドキュメントで、大容量メモリやメモリ負荷の高い仮想化ワークロードに Huge Pages が特に関連すると説明しています。

小規模なインフラ VM は事情が異なります。DNS リゾルバー、軽量なリバースプロキシ、小規模な監視ノード、オートメーションサーバーなどは、割り当てられたメモリのごく一部しかアクティブに使用しない場合があります。その状況では、主な性能要因はアプリケーションの挙動、ストレージのレイテンシ、CPU スケジューリング、ネットワーク経路、外部依存関係などである可能性が高くなります。

ホスト自体にどれだけの仮想化容量を持たせるかまだ検討中であれば、ZimaSpace の ZimaCube と Proxmox の構成例が参考になります。実際に稼働させる予定の VM に対して、ホストに十分な RAM、ストレージ、I/O 容量を確保してから、メモリのチューニングを行うべきです。

Transparent Huge Pages はベースラインに含めるべきです

よくあるベンチマーク上の誤りは、静的 Huge Pages を、THP の恩恵をすでに受けていたシステムと比較してしまうことです。最新の Linux では、適したメモリをより大きなマッピングへ透過的に統合できます。カーネルのドキュメントによると、THP は固定の HugeTLB 予約よりも多くのメモリ管理機能を利用可能な状態に保ち、空きメモリをより柔軟に使用できます。

つまり、実際の比較は「4 KiBページと2 MiBページ」ではないことが多いのです。それは「ホストの通常のTHP動作と、このVM向けに明示的に予約したHugeTLBページ」の比較です。THPがすでに有用な大容量メモリ領域の多くを取り込んでいる場合、静的Huge Pageによる追加効果は控えめかもしれません。

テスト前にホストを確認します。

cat /sys/kernel/mm/transparent_hugepage/enabled
grep -E 'AnonHugePages|HugePages|Hugepagesize' /proc/meminfo

Linuxカーネルは、THPカウンターも /proc/vmstatこれにより、機能が有効だと決めつけるのではなく、ホストが実際にHuge Pageを割り当て、統合しているかどうかを確認できます。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

静的Huge Pageは柔軟性を予測可能性と引き換えにする

Libvirtでは、<memoryBacking>設定を通じてHuge Pageを明示的に要求できます。現在のドメインXMLドキュメントでは、ページサイズを選択し、それらをゲストのNUMAノードに割り当てることがサポートされています。

Proxmoxでは、QEMU設定を通じて同じ基本的な考え方を利用できます。現在のqemu-serverスキーマには、2 MiBと1 GiBのHuge Pageの選択肢に加え、自動選択モードが記載されています。これは機能を簡単に有効化できる点で便利ですが、設定の容易さを速度向上の保証と混同してはいけません。

代償は予約済みメモリです。静的なHugeTLBページは、通常のページング可能なメモリより意図的に柔軟性が低くなっています。32 GBのRAMを搭載し、バースト的に負荷が変化する複数のVMを実行するホストでは、1つのゲストにおける変換オーバーヘッドのわずかな削減よりも、回収可能なメモリのほうが価値を持つ場合があります。ホームラボが動的なメモリ割り当て、オーバーコミット、またはVM密度の急速な変化に依存しているなら、ベンチマーク結果だけでなく機会費用も測定してください。

ホストが大きくなるほどNUMAの整合性が重要になる

単一ソケットのミニPCでは、NUMAは実用上あまり問題にならないかもしれません。しかし、より大規模なワークステーションやデュアルソケットサーバーでは、Huge PageをCPUやメモリの局所性と切り離して評価すべきではありません。Libvirtのメモリバックエンドモデルでは、ページサイズをNUMAノードに関連付けることができ、NUMAのチューニング設定によってゲストメモリの割り当て先を決定できます。

したがって、ベンチマークで一見Huge Pagesの向上が示されても、実際の改善はより良い局所性によるものかもしれません。また、VMがリモートNUMAメモリに繰り返しアクセスしているために、向上が見られない場合もあります。より大規模なホストでは、ページサイズだけを変更するのではなく、CPUピン留め、ゲストNUMAトポロジ、メモリ配置をまとめてテストします。

合成的な見出し数値ではなく、再現可能なA/Bテストを使用する

問うべきなのは、Huge PagesがこれまでにKVMの性能を向上させたことがあるかどうかではありません。向上することはあります。重要なのは、失われるメモリの柔軟性を補えるほど、あなたのVMの性能が向上するかです。

両方の実行で、同じVMイメージ、vCPU数、RAM容量、ストレージパス、CPUモデル、NUMAレイアウト、ワークロードを使用します。メモリのバックエンドが実際に変更されるよう、モードを切り替える間に再起動するか、VMを再起動します。そのうえで、アプリケーションレベルの性能とホストのメモリ動作の両方を記録します。

たとえば、単なるメモリコピーのマイクロベンチマークだけに頼らず、VMの実際の役割に近いデータベースベンチマーク、ビルドワークロード、パケット処理テストを実行します。各条件を数回ずつ繰り返し、中央値とテールレイテンシを比較します。サービスレイテンシを変えない2%の合成メモリ性能向上よりも、実際のワークロードでCPU時間やリクエストレイテンシが一貫して短縮されるほうが、通常は強い根拠になります。

メリットが維持するほど大きいのはどの程度か？

ホームラボでは、しきい値を理念ではなく運用面で判断すべきです。結果が再現可能で、ワークロードが継続的に重要であり、ページを予約してもホストの他の領域にメモリ圧迫が生じないほど十分なRAMがある場合は、静的なHuge Pagesを維持します。

大きなボトルネックを解消した後に行う最適化としてのHuge Pages

VMがCPUバウンド、メモリ容量バウンド、ストレージバウンド、ネットワークバウンドのいずれであるかを確認する前に、Huge Pagesを有効にしないでください。ホームラボでは通常、まず明らかなボトルネックを解消するほうが大きな効果があります。スワップを避けるのに十分なRAM、VMディスク用の高速ストレージ、適切なVirtIOデバイス、適切なvCPUサイズ、そして実際のワークロード上の課題を解決する場合に限ったハードウェアパススルーが重要です。

ホームラボ向けの中古サーバー、ミニPC、NASハードウェアを比較したZimaSpaceの概要でも、同じように、より大きな視点から、仮想化のパフォーマンスはワークロードに適したハードウェアの選択から始まると説明しています。ページサイズのチューニングは、ホストアーキテクチャが適切に整った後に行う二次的な最適化です。

最終結論

Huge Pagesは実際のパフォーマンス上の優位性をもたらしますが、TLBへの負荷を測定できる、大規模で安定したメモリ集約型VMで最も大きな価値を発揮します。一般的な小規模ホームラボサービスでは、管理されたベンチマークで別の結果が示されるまで、デフォルトのメモリ動作を維持してください。

まずホストの通常のTHP設定から始め、実際のワークロードを測定してから、明示的な2 MiB Huge Pagesをテストします。繰り返し実行しても改善が維持され、予約したRAMによってサーバーの他の部分の信頼性や密度が低下しない場合にのみ、使用を続けてください。

よくある質問

1 GiB Huge Pagesは、常に2 MiB Huge Pagesより高速ですか？

いいえ。大きなページは1つのTLBエントリでより広いアドレス空間をカバーできますが、1 GiBの割り当てははるかに粗く、予約も困難です。効果があるかどうかは、ワークロードとホストのメモリ構成によって決まります。

すべてのProxmox VMでHuge Pagesを使うべきですか？

いいえ。Huge Pagesはワークロード固有のチューニングオプションです。小規模または使用率の低いVMでは、ホストメモリの柔軟性を維持するほうが有利な場合がよくあります。

Transparent Huge Pagesを使えば、静的なHuge Pagesは不要ですか？

必ずしもそうとは限りません。THPは柔軟な自動メカニズムである一方、静的なHugeTLBページは、より明示的で予測しやすいバックアップを提供します。同じワークロードで両方を比較してください。

最初に何をテストすべきですか？

まずアプリケーションのスループットまたはレイテンシーを測定し、その後ホストメモリとTLBのメトリクスで仕組みを確認します。TLBミス数の減少は、必要なサービスの改善につながる場合にのみ重要です。