コース受講生向けに用意された記事の翻訳「Linux管理者」.

以前、Linux で Hugepages をテストして有効にする方法について説明しました。
この記事は、実際に Hugepages を使用する場所がある場合にのみ役立ちます。私は、Hugepages が魔法のように生産性を向上させるという見通しに騙される多くの人に会いました。ただし、ヒュージページングは複雑なトピックであり、使用方法を誤るとパフォーマンスが低下する可能性があります。

パート 1: Linux で hugepage が有効になっていることを確認する (オリジナル) ここで)

問題：
システムで HugePages が有効になっているかどうかを確認する必要があります。

解決策：
それは非常に簡単です:

cat /sys/kernel/mm/transparent_hugepage/enabled

次のようなものが得られます。

always [madvise] never

利用可能なオプションのリストが表示されます (いつも、マッドヴィス、決して)、現在アクティブなオプションは括弧で囲まれます (デフォルトでは マバイス).

マバイス という意味です transparent hugepages を使用して明示的に hugepage を要求するメモリ領域に対してのみ有効になります。マッドバイス(2).

常にという意味です transparent hugepages すべてのプロセスに対して常に有効になります。これにより通常はパフォーマンスが向上しますが、多くのプロセスが少量のメモリを消費するユースケースでは、全体のメモリ負荷が大幅に増加する可能性があります。

決して という意味です transparent hugepages Madvise を使用してリクエストされた場合でも含まれません。詳細については、お問い合わせくださいドキュメンテーション Linux カーネル。

デフォルト値を変更する方法

オプション1：直接変更 sysfs (再起動後、パラメータはデフォルト値に戻ります):

echo always >/sys/kernel/mm/transparent_hugepage/enabled
echo madvise >/sys/kernel/mm/transparent_hugepage/enabled
echo never >/sys/kernel/mm/transparent_hugepage/enabled

オプション2: 変更された構成でカーネルを再コンパイルして、システムのデフォルトを変更します (このオプションは、カスタムカーネルを使用している場合にのみ推奨されます)。

常にデフォルトで設定するには、次を使用します。

CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
# Comment out CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y

Madvise をデフォルトとして設定するには、次を使用します。

CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y
# Comment out CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y

パート 2: HugePages の長所と短所

Hugepages を使用する際の利点、欠点、および考えられる落とし穴を選択的に説明していきます。技術的に複雑で衒学的な記事は、Hugepages が万能薬だと思い込んでいる人々にとっては理解するのが難しいと思われるため、簡潔にするために正確さを犠牲にします。多くのトピックは非常に複雑であるため、大幅に簡略化されていることに留意してください。

ここでは、Linux を実行している 64 ビット x86 システムについて話していること、および最近のほとんどすべての Linux の場合と同様に、システムが透過的なヒュージページをサポートしていると単純に仮定していることに注意してください (ヒュージページが上書きされないことは欠点ではないため)。環境。

以下のリンクにさらに技術的な説明を添付します。

仮想メモリ

C++ プログラマであれば、メモリ内のオブジェクトには特定のアドレス (ポインタ値) があることをご存知でしょう。

ただし、これらのアドレスは必ずしもメモリ内の物理アドレス (RAM アドレス) を反映しているわけではありません。これらは仮想メモリ内のアドレスを表します。プロセッサには、カーネルが仮想メモリを物理的な場所にマップするのに役立つ特別な MMU (メモリ管理ユニット) モジュールがあります。

このアプローチには多くの利点がありますが、最も重要なものは次のとおりです。

パフォーマンス (さまざまな理由による)。
プログラムの分離。つまり、どのプログラムも別のプログラムのメモリから読み取ることができません。

ページとは何ですか?

仮想メモリはページに分割されます。個々のページは特定の物理メモリを指します。RAM 内の領域を指すことも、ビデオカードなどの物理デバイスに割り当てられたアドレスを指すこともできます。

扱うページのほとんどは RAM をポイントしているか、スワップされており、ハードドライブまたは SSD に保存されています。カーネルは各ページの物理レイアウトを管理します。スプーフィングされたページにアクセスすると、カーネルはメモリにアクセスしようとしているスレッドを停止し、ページをハードドライブ/SSD から RAM に読み取り、スレッドの実行を継続します。

このプロセスはストリーム透過的です。つまり、必ずしも HDD/SSD から直接読み取る必要はありません。通常のページのサイズは 4096 バイトです。 Hugepages のサイズは 2 メガバイトです。

翻訳関連バッファ (TLB)

プログラムがメモリのページにアクセスするとき、CPU はどの物理ページからデータを読み取るかを認識している必要があります (つまり、仮想アドレスマップを持っている必要があります)。

カーネルには、使用されているページに関するすべての情報が含まれるデータ構造 (ページテーブル) があります。このデータ構造を使用すると、仮想アドレスを物理アドレスにマップできます。

ただし、ページテーブルは非常に複雑で遅いため、プロセスがメモリにアクセスするたびにデータ構造全体を分析することはできません。

幸いなことに、私たちのプロセッサには、仮想アドレスと物理アドレス間のマッピングをキャッシュする TLB があります。つまり、最初のアクセス試行ではページテーブルを解析する必要がありますが、その後のページへのアクセスはすべて TLB で処理できるため、高速な操作が可能になります。

物理デバイスとして実装されているため (そもそも高速であるため)、その容量には制限があります。したがって、より多くのページにアクセスしたい場合、TLB はすべてのページのマッピングを保存できず、プログラムの実行が大幅に遅くなります。

Hugepages が助けに来ます

では、TLB オーバーフローを回避するにはどうすればよいでしょうか? (プログラムには依然として同じ量のメモリが必要であると想定しています)。

ここでHugepagesが登場します。 4096 つの TLB エントリだけを必要とする 2 バイトの代わりに、512 つの TLB エントリがなんと XNUMX メガバイトを指すことができるようになりました。 TLB に XNUMX 個のエントリがあると仮定します。ここでは Hugepage なしで一致させることができます。

4096 b⋅512=2 MB

では、どうやってそれらと比較できるのでしょうか。

2 MB⋅512=1 GB

これが、Hugepages が素晴らしい理由です。それほど労力をかけずに生産性を向上させることができます。ただし、ここには重要な注意点があります。

Hugepage のスプーフィング

カーネルは、各メモリページの使用頻度を自動的に監視します。十分な物理メモリ (RAM) がない場合、カーネルは重要度の低い (使用頻度の低い) ページをハードディスクに移動して、より重要なページのために RAM を解放します。
原則として、同じことが Hugepage にも当てはまります。ただし、カーネルが交換できるのはページ全体のみであり、個々のバイトを交換することはできません。

次のようなプログラムがあるとします。

char* mymemory = malloc(2*1024*1024); // Возьмем это за одну Hugepage!
// Заполним mymemory какими-либо данными
// Сделаем много других вещей,
// которые приведут к подмене страницы mymemory
// ...
// Запросим доступ только к первому байту
putchar(mymemory[0]);

この場合、カーネルは、ユーザーが 2 バイトを読み取るために、ハードドライブ/SSD から 4096 メガバイトもの情報を置き換える (読み取る) 必要があります。通常のページの場合、ハードドライブ/SSD から読み取る必要があるのは XNUMX バイトのみです。

したがって、hugepage がオーバーライドされた場合、ページ全体にアクセスする必要がある場合にのみ読み取りが速くなります。これは、メモリのさまざまな部分にランダムにアクセスしようとしていて、数キロバイトを読み取るだけの場合は、通常のページを使用し、他には何も心配する必要がないことを意味します。

一方、メモリの大部分に順次アクセスする必要がある場合は、hugepage を使用するとパフォーマンスが向上します。ただし、（抽象的なソフトウェアを使用せずに）自分でテストして、何がより速く動作するかを確認する必要があります。

メモリ内の割り当て

C を作成する場合は、次を使用してヒープから任意に小さい (またはほぼ任意に大きい) 量のメモリを要求できることがわかります。 malloc()。 30 バイトのメモリが必要だとします。

char* mymemory = malloc(30);

プログラマにとっては、オペレーティングシステムに 30 バイトのメモリを「要求」し、仮想メモリへのポインタを返しているように見えるかもしれません。でも実は malloc () 関数内から呼び出す単なる C 関数です brkとsbrk オペレーティングシステムにメモリを要求または解放します。

ただし、割り当てごとにさらに多くのメモリを要求するのは非効率です。いくつかのメモリセグメントがすでに解放されている可能性が最も高いです (free())、再利用することができます。 malloc() 解放されたメモリを再利用するための非常に複雑なアルゴリズムを実装します。

同時に、すべてのことはあなたにとって気づかれずに起こっているので、なぜ心配する必要があるでしょうか？しかし、挑戦だからこそ、 free() そういう意味ではありませんメモリは必然的に直ちにオペレーティングシステムに返されます。.

記憶の断片化というものがあります。極端な場合には、数バイトだけが使用されているヒープセグメントが存在し、その間のすべてのバイトが解放されることがあります。 (free()).

メモリの断片化は非常に複雑なトピックであり、プログラムへのわずかな変更でも重大な影響を与える可能性があることに注意してください。ほとんどの場合、プログラムによって重大なメモリの断片化が引き起こされることはありませんが、ヒープの一部の領域で断片化の問題が発生した場合、hugepage によって状況が悪化する可能性があることに注意する必要があります。

hugepage の選択的使用

この記事を読んだ後は、プログラムのどの部分が hugepage を使用することでメリットを得られるのか、どの部分がメリットを得られないのかを判断したことになります。それでは、そもそも hugepage を有効にする必要があるのでしょうか?

幸いなことに、使用できます madvise()ヒュージページングが役立つメモリ領域に対してのみヒュージページングを有効にします。

まず、hugepages が madvise() モードで実行されていることを確認します。説明書記事の冒頭に。

次に、使用します madvise()hugepage を使用する場所をカーネルに正確に指示します。

#include <sys/mman.h>
// Аллоцируйте большое количество памяти, которую будете использовать
size_t size = 256*1024*1024;
char* mymemory = malloc(size);
// Просто включите hugepages…
madvise(mymemory, size, MADV_HUGEPAGE);
// … и задайте следующее
madvise(mymemory, size, MADV_HUGEPAGE | MADV_SEQUENTIAL)

このメソッドは、メモリの管理方法についてカーネルにアドバイスするだけであることに注意してください。これは、カーネルが特定のメモリに対して自動的に hugepage を使用するという意味ではありません。

ドキュメントを参照してください (マンページ)アドバイスメモリ管理について詳しく学び、 madvise(), このトピックの学習曲線は信じられないほど急です。したがって、本当に上達したい場合は、肯定的な結果が期待できる前に、数週間読んでテストする準備をしてください。

何を読むべきですか？

質問があります？コメントに書いてください！

出所： habr.com

HugePages の長所と短所