サーバーと仮想マシン

LinuxにおけるTransparent Huge Pages――パフォーマンス向上につながるのか、それとも問題なのか？

透過型HugePages Linuxでは、TLBミスの減少、ページテーブルのオーバーヘッドの低減、ひいてはスループットの向上が期待される一方で、管理者からはレイテンシの急上昇や応答時間の変動が報告されている。ここでは、THPがいつ パフォーマンス向上ツール リスクが潜んでいる箇所や、ワークロードを確実に実行できるように設定する方法について。.

中心点

以下の要点により、THPを素早く把握し、適切に設定することができます。各行には最も重要な点が示されています。重心.

ダイナミクス: THPは、4 KBのページを自動的に2 MBのページにまとめ、再び分割します。.
メリット: 大規模な連続データ領域において、TLBミスが減少し、CPUのオーバーヘッドが低減される。.
デメリット: 圧縮処理によりレイテンシの急激な変動が生じる可能性があり、データベースやVMにとっては扱いが難しい。.
モード: always, madvise, never – セットアップでは、たいてい「madvise」または「never」が適しています。.
練習: 重要なデータベースには静的なHugePagesを、アプリケーションにはTHPを適宜適用するハイブリッドなアプローチ。.

THPがカーネル内でどのように動作するか

私はTHPを、追加の 抽象化 メモリ管理において：カーネルは、アクセスパターンとメモリ配置が条件を満たすやいなや、隣接する4KBのページを2MBのフォリオに「統合」する。この処理により、ページテーブルのエントリ数が削減され、その結果、 エムエムユー 負荷を軽減し、TLBヒット率を向上させます。パターンが変化したりメモリが断片化したりすると、カーネルは再び4KBページにデプロモーションを行い、ホットデータとコールドデータの柔軟性を維持します。このプロモーションとデプロモーションのサイクルは、仮想アドレスレイアウトに変化がないアプリケーションにとっては透過的に行われます。最新のハードウェア上では、バックグラウンドでのオーバーヘッドが前面に出てこない限り、この仕組みが顕著な効果をもたらします。.

明らかなメリットが得られるワークロード

比較的大きな、連続したメモリ領域で、 逐次的な アクセス処理では、THPの恩恵が特に顕著に現れます。インメモリキャッシュ、分析エンジン、および大規模な配列を多用する数値HPCコードにおいて、その利点が見られます。 C++ハッシュテーブルに関する実証報告によると、TLBミスが減少してCPUの管理負荷が軽減されることで、2桁のパフォーマンス向上が確認されています。また、主に読み取り中心でキャッシュに適したアクセスパターンを示すデータベースについても、カーネルがコストのかかるコンパクションをトリガーしない限り、パフォーマンス向上が期待できます。総じて、多くの場合、 スループット, 、データがメモリ内に「広く」配置され、TLBの負荷が低下する場合。.

レイテンシーのピークが発生する理由

THPには、連続した物理的な メモリブロック; 断片化が激しい場合、カーネルは領域を移動・圧縮する必要があります。この圧縮処理は通常バックグラウンドで行われますが、負荷が高まるとフォアグラウンドに移行し、処理の停滞を引き起こすことがあります。中央値は良好に見えても、まさにこうした瞬間がP99レイテンシを押し上げているのです。そのため、私は定期的にメモリの断片化, 、THPを積極的に有効にする前に。レイテンシが重要なサービスを運用している場合は、こうしたスパイクに注意を払い、必要に応じてデフラグの処理を抑制するか、THPを無効にして、 ジッター を避けなければならない。

データベース、仮想化、およびMySQLのパフォーマンス

リレーショナル データベース MySQL や PostgreSQL のようなデータベースは、ストレージのコンパクションによる予期せぬ停止に敏感です。THP 環境下では、平均値は安定しているように見えても、「mysql performance」が変動するのを何度も確認しました。仮想化環境では、追加のレイヤーによって短い遅延が倍増するため、信頼性の高い応答時間を確保することが困難になります。 Oracleや大規模なMySQLインスタンスを運用している場合は、一貫したレイテンシを実現するために、静的なHugePagesを使用し、THPを無効にしたほうが、たいていの場合、より良い結果が得られます。重要なVMやリアルタイムサービスについても同様であり、ここでは決定論的な挙動が明らかに優先されるためです。 スループット を持っています。

THPの正しい調整方法：モードとスイッチ

私はSysfsと カーネル-Cmdline パラメータ。このモードは /sys/kernel/mm/transparent_hugepage/enabled そして、例えば「always madvise [never]」と表示され、角括弧で囲まれた項目がアクティブになっています。レイテンシが重要なノードについては、次のように設定します。 echo never > /sys/kernel/mm/transparent_hugepage/enabled そして、同じ設定を .../defrag, 、過度な圧縮が行われないようにするためです。混合ワークロードの場合は、私はよく マドヴァイズ そして、適切な領域のみに MADV_HUGEPAGE. 完全に無効にするには、次のように記述します transparent_hugepage=never をカーネルのコマンドラインに入力し、ブートローダーを更新してください。.

THPモードの比較と推奨設定

次の表は、一般的な モード を参考にし、サーバーの役割ごとに迅速に判断を下すのに役立っています。.

モード	メリット	リスク	こんな人に向いている	ヒント
常に	自動効果を最大限に引き出し、より広範囲にアドレスへんかんバッファ-負担軽減	コンパクションの遅延が発生する可能性が高まる	P99の厳格な目標値を設定していないアプリサーバー	負荷試験を実施した後にのみ使用すること
マドヴァイズ	明確なメリット、予期せぬ事態の減少	アプリ／ライブラリのオプトインが必要	混合ワークロード、キャッシュ、分析	グッドデフォルトホスティング用
決して	安定したレイテンシ、THPによる副作用なし	THPブーストなし	データベース、仮想マシン、リアルタイムサービス	静的なHugePagesと組み合わせる

ホスティングにおけるTHPと静的HugePagesの比較

静的なHugePagesは私にとって非常に役立っています不変レイテンシについては、事前に予約しておくため、カーネルがバックグラウンドでコンパクションを行わないことが原因です。大規模なデータベースや長時間稼働するJVMの場合、私はその数を余裕を持って設定し、メモリへのアクセス経路を短く保っています。一方、THPは利便性が高く、負荷がそれほど高くない環境では自動的にパフォーマンス向上が期待できます。多くの環境では、この2つを組み合わせています。WebノードやアプリケーションノードにはTHPを、DBサーバーには静的なHugePagesを採用しています。この概要記事には、その良い入門情報が掲載されています。ホスティングにおけるHugePages, 、これを起点として、微調整に入る前に、 プロフィール 1ロールごとに設定する。.

WordPress、オンラインショップ、マイクロサービスの実践ガイド

小規模から中規模の ワードプレス-サイトでは、よくTHPを「madvise」モードで有効にし、実際の負荷下でのレイテンシを確認しています。PHP-FPM、キャッシュ、およびWebプロセスが大規模な読み取り領域を保持している場合、顕著なメリットが得られます。大規模なECサイト用データベースやマルチテナント環境では、THPを試用しますが、P95/P99が上昇し始めたら速やかに無効にします。本番環境のデータベースホストでは、ほぼ常に静的なHugePagesを採用し、THPは無効にしています。この方針により、アプリケーションサーバーが自動調整による影響を最小限に抑えつつ、信頼性の高い応答時間が確保されます。 リスク を使用します。

モニタリングと重要な数字

THP統計、圧縮カウンター、および アドレスへんかんバッファ-私のオブザーバビリティ設定におけるミス。以下のファイル： /sys/kernel/mm/transparent_hugepage/, vmstat や、次のようなツールなど パーフェクト ホットスポットを素早く特定するのに役立ちます。私は、P95/P99レイテンシ、1秒あたりのコリプス数、およびKcompactdのCPU使用時間に注目しています。NUMAシステムでは、不適切な割り当てが問題を隠してしまうため、メモリの局所性も確認しています。このガイドは、そのための良い入門書です。 NUMAローカリティ. そこで、THPが有効かどうかを数値で証明する。危害, 、直感に頼るのではなく。.

トラブルシューティングと迅速なロールバック

レイテンシが急に上昇した場合は、THPを一時的に 決して 実行し、変更前後の測定値を比較します。それでも現象が続く場合は、JVMにおけるフラグメンテーション、I/O待ち時間、およびガベージコレクタのフェーズを確認します。THPが原因であると判明次第、恒久的に transparent_hugepage=never あるいは、ターゲットを絞ったオプトインで「madvise」に切り替えます。負荷が極めて高い期間には、ピーク負荷を平準化するために、過度なデフラグを停止します。まず、 ジッター 消えてしまった場合は、段階的に元に戻し、サーバーロールを選択したことを記録します。.

よく見落とされがちな点：匿名型とファイルベース型のTHPおよびフォリオ

私は、匿名メモリ（ヒープ、スタック、ファイルを使用しないマッピング）とファイルベースのページ（ページキャッシュ）を区別しています。THPは匿名メモリ向けに確立されており、 有効/デフラグ およびユーザースペース・ヒント MADV_HUGEPAGE 制御されます。共有メモリ領域（tmpfs/shmem）には、専用のスイッチが用意されています /sys/kernel/mm/transparent_hugepage/shmem_enabled, 、同様のルールを適用するものです。最近のカーネル世代で広く採用されているフォリオ方式は、内部表現をより効率的に統合し、カーネル側にとって可変的でより大きな単位への道を開く。日常の使用においては、フラグメンテーションや負荷が支配的でない限り、THPのパフォーマンスがより堅牢になったと実感している。.

微調整：関連するカーネルおよびsysfsパラメータ

再現性のある結果を得るために、一律に「常に／決して」と設定するのではなく、目的のパラメータを個別に調整しています：

/sys/kernel/mm/transparent_hugepage/enabled: 匿名THP用の基本モード。.
/sys/kernel/mm/transparent_hugepage/defrag: デフラグの強度（レイテンシの問題がある場合は、設定を控えめにするか、無効にしてください）。.
/sys/kernel/mm/transparent_hugepage/khugepaged/: スキャン間隔とバックグラウンドスレッドの制限（例：. scan_sleep_millisecs, スキャンするページ数)、CPU負荷とコラープスをバランスよく調整するため。.
/proc/sys/vm/compaction_proactiveness: スパイクが問題となる場合は、早期にプロアクティブな圧縮を抑制する。.
/proc/sys/vm/compact_unevictable_allowed: 押し込みにくい部分であっても圧縮してよいのか――保守的なアプローチの方が、多くの場合、より安定している。.
/proc/sys/vm/swappiness: スワップニスが大きいと、負荷がかかった際にリクレイムが増加する。その際、THPを頻繁に分割する必要が生じるため、レイテンシの目標値としては低い値を設定している。.

補足として、以下の測定値を読み取ります /proc/vmstat (例 thp_fault_alloc, thp_collapse_alloc, thp_split, compact_stallそして /proc/meminfo (AnonHugePages, ShmemHugePages). これにより、THPが実際に利用されているかどうか、またピーク時に分割や集約が増加しているかどうかを確認できます。.

スワップ、リクレイム、および「ディファード・スプリット」„

メモリ負荷が高まると、「大きく、連続した」ページという幻想は崩れ去ります。リクレイムやスワップでは、2MBのページを直接スワップアウトすることはできず、まず4KBのページに分割されます。この分割処理は、後で処理される「Deferredキュー」を介して行われます。実際には、これは、分割処理が後処理される際に、短時間の負荷のピークが数秒後にレイテンシのアーティファクトを引き起こす可能性があることを意味します。私は以下の方法でこの問題を緩和しています：

低い vm.swappiness あるいは、レイテンシノードにおけるスワップの省略、,
メモリサイジングにおけるヘッドルーム予算の確保（99-%の割り当てなし）、,
保守的な デフラグ‑設定を調整することで、今後の分割作業の頻度を減らすことができます。.

NUMAの影響とAutoNUMA

THPは、蓄熱装置が機能して初めてその効果を発揮します。 ローカル CPU に関してですが。NUMA ホストでは、過度な圧縮を行うとローカルな空き領域が不足し、その結果、リモート割り当てが発生することを確認しています。THP 自体は有効であるにもかかわらず、レイテンシが増加してしまいます。私は次のように対応しています：

サービスごとのCPUおよびメモリのアフィニティを定義する（例：. ヌマクトル （サービス・ラッパー内）、,
kernel.numa_balancing（カーネル・ヌマ・バランシング 意識的に選択する：ピン留めが安定しているサービスでは多くの場合、その方が有利ですが、動的な負荷がある場合には、,
NUMAローカリティのモニタリング結果をTHP評価に含める（上記のNUMAローカリティに関するリンクを参照）。.

リモートでの割合が増えると、THPのTLBパフォーマンスの向上が相対化されるため、まずは「ローカル性」を優先し、その次にTHPチューニングを優先すべきである。.

仮想化：ホストとゲストを明確に分離する

KVM環境では、ホストとゲストの決定を厳格に分離しています。ホスト上では、すべてのVMに対して決定論的なレイテンシを確保しています。具体的には、静的なHugePages（hugetlbfs経由で1 GB/2 MB）を使用し、THPを無効化することで、コンパクションがすべてのゲストに同時に影響を与えないようにしています。ゲスト内では、ベアメタル環境と同様に扱います。データベースVMには静的なHugePagesを割り当て、THPは「never」に設定し、Web／アプリVMには「madvise」の使用を許可します。また、以下の点も考慮に入れています。 バルーン また、ゲストメモリのオーバーコミットを抑制し、THPクォータを引き下げます。レイテンシの目標値に応じて、バルーニングを抑制するか、固定RAMの割り当てを増やすようにしています。 KSM重複排除はメモリを節約しますが、大きなページサイズとの相性は限定的です。そのため、レイテンシの制約が厳しいホストではKSMを有効にしません。.

コンテナとKubernetes

コンテナ環境では、THP はノードのカーネル固有の特性となります。私はワーカー上でシステムモードを設定し、個々のポッドが独自の THP ポリシーオーバーライドを持たないことを容認します。実践上のヒント：

負荷が混在するノード： マドヴァイズ 基本モードとして、次のようなライブラリ ジェマロック あるいは、特定のアプリケーションを madvise() オプトインのままにする。.
ヘッドルームを備えたメモリ制限：余裕のないcgroupでは、Reclaimによってスプリットが発生しやすくなるが、ある程度のバッファを確保することでP99の安定性が向上する。.
段階的な展開：ノードプールAはTHP変更版、Bは対照群 – P95/P99およびCPU時間を kcompactd 比較する。.

JVM、malloc、および実行環境

JVMのヒープはTLBミスが少ないほどパフォーマンスが向上しますが、ML/GCフェーズは予期せぬ中断を嫌います。大規模なヒープで中断時間を一定に保つために、私は静的なHugePagesを使用しています（-XX:+UseLargePages hugetlbfsを使用し、THPは除外します。それほど機密性が高くないJVMサービスでは、 マドヴァイズ GCメトリクスを綿密に追跡している限り、THPのメリットを最大限に活かすことができる。. malloc‑実装によって挙動が異なります： ジェマロック 以下の方法で マドヴァイズ- THP向けに大規模なアリーナをより適切に準備する。glibcのmallocはアリーナの数が増えるにつれてスケーリングするため、断片化を招く可能性がある。ここでは、レイテンシが重要なプロセスにおいてアリーナの数を減らし、THPへの昇格を容易にする。.

テスト戦略と確実な展開

私は、利益と副作用を明確に区別するために、明確な手順に従っています：

ベースラインの記録：P50/P95/P99、CPUサイクル、, perf stat -e dTLB-load-misses,iTLB-load-misses, /proc/vmstat‑カウンター。.
「madvise」モードを有効にし、特定のコンポーネントをオプトインにして、再度測定を行う。.
圧縮を抑制する (デフラグ より保守的な、, compaction_proactiveness （下げる）して、再度測定する。.
テストにおいて、ピーク負荷とバックグラウンドジョブ（バックアップ、再インデックス、デプロイ）を明示的に再現する――そうすることで、ジッターが明らかになる。.
P95/P99が安定している場合にのみ、より多くのサービスへこの変更を適用する。そうでない場合は、「never」または静的なHugePagesに戻す。.

日常生活チェックリスト

目標を明確に：スループットか、レイテンシの安定性か？それに応じてモードを選択する。.
本番環境に「always」を導入する前に、断片化を確認してください。.
まずNUMAロケーションを固定し、その後THPを微調整する。.
スワップとリクレイムに注目：レイテンシ重視のサービス向け低スワップ性。.
khugepagedパラメータはワークロードに合わせて調整し、安易に標準設定を使用しないこと。.
データベース／VMの場合：静的なHugePagesを優先し、THPは「never」に設定する。.
ロールバック計画を文書化し、自動化する。.

簡単にまとめると

THPは明確な ブースター ワークロードが大規模な読み取り用メモリ領域を利用し、厳格なP99目標が設定されていない場合です。データベース、仮想化、リアルタイムサービスにおいては、一貫したレイテンシを重視し、静的なHugePagesを採用しています。混合サーバー環境では、安全な妥協点として「madvise」を選択し、アプリケーションごとに最適化を行うようにしています。綿密な測定、適切なモニタリング、そして明確なロールバック戦略により、予期せぬ高額な出費を防ぐことができます。このようにして、 透過型HugePages 生産システムの信頼性を損なうことなく、これを向上させる。.