☰

サーバーが巨大なページ (メモリ ページ サイズ) を使用する必要があるかどうかを知る方法

tag-icon • tag-icon linux redhat memory central-processing-unit mtu
サーバーが巨大なページ (メモリ ページ サイズ) を使用する必要があるかどうかを知る方法

クラスター内に複数のサーバーがあり、一般的にどのような場合に巨大なページを構成する必要があるかを知りたいです。

私もいくつか質問があります

  1. 「メモリ ページ サイズ」は巨大ページと同じですか?

私のLinuxサーバーでは、デフォルトのメモリページサイズを確認するために次のコマンドを入力しました。

grep Hugepagesize /proc/meminfo

Hugepagesize: 2048 kB

getconf PAGESIZE

4096

  1. しかし、ここでわかるように、異なる結果が得られます。なぜでしょうか?

  2. 巨大ページを使用する場合のリスクは何ですか?

  3. 透過的な巨大ページを無効にする - HUGE PAGES オプションを無効にすることを意味しますか?

答え1

Hugepages は、アプリケーションがランダム アクセスを行う大規模なマッピングを必要とする場合に興味深いものです。これは、Translation Lookaside Buffer (TLB) にとって最悪のケースだからです。TLB エントリのマッピングの粒度とトレードオフになります。

ページ (hugepage を含む) は、同じサイズの物理メモリ ブロックにのみマップでき、そのサイズに揃えることができます。したがって、2 MB の hugepage は物理 RAM の 2 MB 境界にマップする必要があり、1 GB の hugepage は 1 GB 境界にマップする必要があります。これは、下位ビットがページ内のデータをアドレス指定し、ここにオフセットを追加できないためです。

つまり、通常、hugepages は物理メモリがまだ断片化されていないシステム起動時に予約されます。hugepages を認識するアプリケーションは、hugetlbfsそれらを割り当てるために使用できます。

カーネル パラメータを使用して、hugepages のサイズを 2MB にするか 1GB にするかを決定する必要があります。これらを混在させることはできません。通常の 4kB ページは常に利用可能です。

最も一般的な使用例は仮想マシンです (qemu/kvm は hugepages を使用できます)。これにより、VM のメモリ マッピング全体を少数の TLB エントリに保持できるため、エントリが削除されることはなく、VM 内のメモリ アクセスにはゲスト コンテキスト内のページ テーブル検索のみが必要になります。

一部のデータベース システムも hugepages をサポートしていますが、これは通常、大規模なデータセットとインデックスを扱う場合にのみ役立ちます。

質問：

  1. 通常 (4kB) ページと巨大 (2MB または 1GB) ページがあります。ページ サイズを照会すると、通常ページのサイズが取得され、巨大ページ サイズを照会すると、巨大ページの設定が取得されます。通常ページと巨大ページはどちらも並行して使用できますが、異なる巨大ページ サイズを混在させることはできません。

  2. これらは 2 つの異なるものであるため、異なる結果が得られます。通常のページのサイズはハードウェアで固定されているため、設定ではありません。

  3. 巨大ページは早期に割り当てる必要があり、メモリは技術的には「無料」ですが、巨大ページ対応アプリケーション以外では使用できないため、これらのアプリケーション以外のすべてのアプリケーションでは使用可能なメモリが少なくなります。通常、これは問題ではありません。なぜなら、VM やデータベースなどのメモリを大量に消費するアプリケーション専用のマシンでは巨大ページを使用するからです。

  4. 透過的な hugepages は、メモリをバッファやキャッシュとして使用できるようにし (#3 とは反対)、大きなメモリ ブロックをマップするアプリケーションに hugepages を提供しようとします。そのため、hugepage に対応していないアプリケーションでも、その恩恵を受けることができます。つまり、2MB/1GB のメモリ ブロックを要求するアプリケーションには、可能な場合は hugepage が提供されます。これがパフォーマンスの向上につながるか低下につながるかは、アプリケーションによって異なります。hugepage に対応するアプリケーションがあり、メモリを手動で割り当てたい場合は、THP を無効にする必要がありますが、hugepages に対応していないデータベース アプリケーションがあるシステムでは、おそらく恩恵を受けるでしょう。

答え2

巨大なページの明らかな使用例は、PageTables (/proc/meminfo で確認可能) が数十 GB になったときです。これは、メモリを追跡するだけでメモリと CPU のオーバーヘッドが大きくなることを意味します。これは、メモリの巨大なチャンク、多数のプロセス、またはその両方で発生します。多くの場合、データベース アプリケーションで発生します。

巨大ページにより、1 つのページ テーブル エントリが 4 KB ではなく 2,048 KB など、はるかに多くのメモリをアドレス指定するようになったため、オーバーヘッドが大幅に削減されました。(他のプラットフォームではサイズが異なり、たとえば AIX on POWER では 16 MB の大規模ページがサポートされています。)

Linux 上の巨大ページはファイル キャッシュには使用できない可能性があり、非共有メモリの malloc() に数 MB かかるため、煩わしく非効率的です。そのため、管理者は、特定の目的にのみ使用できる巨大ページ プールを割り当てる必要があります。これが巨大ページを使用する際の欠点です。

透過的な巨大ページ (THP) は、連続したメモリを巨大ページに自動的に「デフラグ」することで、管理の煩わしさを軽減します。このアイデアは、事前に割り当てられた巨大ページをオプションにするものです。利点はワークロードに非常に固有であり、CPU を消費しすぎて価値がない可能性があります。THP を無効にすると、巨大ページを手動で割り当てることができます。THP をオフにして、データベースの共有メモリ セグメントを巨大ページに配置するだけでよい場合もあります。

Linux の巨大ページに関する最後の不満は、管理が面倒だということです。

  • 共有メモリは 1 つのインターフェイスを使用しますが、他のインターフェイスには hugetlbfs ライブラリとファイル システムを使用します。
  • 巨大ページを過剰に割り当て、アプリケーションがそれを使用するように構成しないと、メモリが「無駄」になる可能性があります。
  • そのページ数はメモリの割合ではなくページ数であるため、各ホストのサイズに合わせて調整する必要があります。
  • 多くの場合、巨大なページを割り当てる機能は 1 つのグループに制限されており、データベース ユーザーを切り替えると予期しないメモリの浪費が発生する可能性があります。

関連情報