記憶について語り続ける-ページ共有

この記事は、一般的な仮想化環境のメモリと、特にWindows Server 2008 R2 SP1に登場するHyper-Vダイナミックメモリテクノロジーを扱った記事シリーズの2番目です。

最初の部分： habrahabr.ru/blogs/virtualization/93241

ここでは、ページ共有と呼ばれる「メモリ割り当て」のテクノロジーの1つについて説明します。

どのように機能しますか？

ページ共有は、ハイパーバイザーの動的メモリ割り当ての技術の1つであり、仮想マシンが物理的に使用可能なメモリよりも多くのメモリを割り当てることを可能にします。つまり、英語では「メモリオーバーコミットメント」と呼ばれます。



この技術の動作原理は、一部のデータ圧縮アルゴリズムに似ています。 それはすべて、ハイパーバイザーがシステムで使用可能なメモリのすべてのページを「シャベル」し、各ページのチェックサム（ハッシュ）を計算するという事実から始まります。 取得した値は特別なテーブルに入力されます。 次に、ハイパーバイザーはテーブル内で同じチェックサム値を探し、一致が見つかった場合、対応するページのビットごとの比較を実行します。 完全に同一のページが見つかった場合、それらのコピーは1つだけ残り、その後、仮想マシンはアクセス時に自動的にリダイレクトされます。 これは、仮想マシンの1つが「共有」ページに変更を加えるまで正確に行われます。 次に、このページの別のコピーが作成され、「共有」されなくなりますが、1台の仮想マシンでのみ使用されます。 残念ながら、ビット単位の比較を使用してテーブル内の一致をさらに検索するメモリの「シャベル」とハッシュの計算は、非常にリソースを消費し、時間がかかり、大量のメモリを使用すると数時間かかる可能性があります。

ページ共有、TLB、大容量メモリページ、すべてすべて

まず、連想変換キャッシュ（Translation Lookaside Buffer、以下TLBと呼びます）が必要なメモリの大規模なページ（Large Memory Pages、以下LMPと呼びます）の一般的な動作原理を見てみましょう。ページ共有。 これは、AMDのエンジニアであるAlan Zeichickが彼の記事に書いていることです（この記事ではJava仮想マシンのメモリを操作することについて述べていますが、これは原則としてコンピューター仮想化にも当てはまります。 こちら ）：

すべてのx86互換プロセッサ、およびすべての最新の32ビットおよび64ビットオペレーティングシステムは、物理メモリおよび仮想メモリのページベースの編成を使用します。 アプリケーションごとに、ページの仮想アドレスと物理アドレスがページテーブルを使用して比較されます。 このマッピングプロセスを高速化するために、最新のプロセッサは、最近アクセスされた物理アドレスと仮想アドレスのマッピングをキャッシュする変換ルックアサイドバッファー（TLB）を使用します。

通常、アプリケーションに割り当てられたメモリは連続的ではなく、多くの場合、メモリページは断片化されています。 しかし、メモリページのテーブルはアプリケーションから物理アドレスを隠すため、アプリケーションは、提供されるメモリ領域が連続していると「考え」ます。 類推すると、ファイルシステムで直接動作しないアプリケーションには、個々のファイルの断片化に関する手がかりがありません。

実行中のアプリケーションがメモリにアクセスすると、プロセッサはページテーブルを使用して、アプリケーションが使用する仮想アドレスを物理アドレスに変換します。 前述のように、このプロセスを高速化するために、キャッシングシステムが使用されます-連想変換バッファ。 要求されたアドレスがTLBにある場合、ページテーブル全体で一致を見つける必要がないため、プロセッサは要求をはるかに高速に処理できます。 したがって、要求されたアドレスがTLBキャッシュにない場合、ページテーブル内の仮想アドレスと物理アドレスを一致させる標準操作が実行され、その後のみ要求を処理できます。

ページの数が多いため、TLBキャッシュのパフォーマンスは非常に重要です。 OSを実行している標準の32ビットサーバーでは、Windows、Linux、または4 GBのRAMを備えた他のUnixであるかどうかは関係ありません。ページテーブルには、4キロバイトページごとに100万エントリが含まれます。 たとえば、64ビットOSと32 GBのメモリがあるとしますか？ それは、最大800万の4キロバイトのページになります。

さらに：

なぜこの技術の使用[大きなページ]がより便利なのですか？ アプリケーションが比較的長い時間アクセスされた1 MB（1024 KB）の連続データを読み取ろうとしているとしましょう（つまり、この要求はTLBキャッシュに保存されていません）。 メモリページのサイズが4 KBの場合、これは256ページにアクセスする必要があることを意味します。 ページテーブルで256の検索を実行する必要があり、何百万ものレコードを持つことができます。 それには多くの時間がかかります。

ここで、ページサイズが2 MB（2048 KB）であるとします。 この場合、必要な1 MBデータブロックが完全に1ページにある場合は1回だけ、そうでない場合は2回ページテーブルを検索する必要があります。 TLBがまだ使用されている場合、プロセスはさらに高速になります。

スモールページの場合、TLBにはL1キャッシュ用の32エントリとL2キャッシュ用の512エントリが含まれます。 各エントリは4キロバイトのページに対応するため、TLB全体では2 MBの仮想メモリしかカバーされないことがわかります。

大きなページの場合、TLBには8つのエントリが含まれます。 ここの各エントリは2 MBのメモリをアドレス指定するため、TLBは16 MBの仮想メモリをアドレス指定します。 メモリを大量に消費するアプリケーションを使用する場合、このメカニズムははるかに効率的になります。 たとえば、アプリケーションが2 GBのデータを読み取ろうとしているとします。 何が高速になりますか-キャッシュされた数千の2メガバイトのページを読み取るか、50万の小さな4キロバイトのページを「シャベル」しますか？

簡単な算術を使用して、さまざまなメモリ量のページテーブルのエントリ数を計算できます。 4キロバイトのページサイズを受け入れた場合、4 GBのメモリの場合は100万だけになります。 32 GBの場合-すでに800万、64 GBの場合-1600万レコード、1 TBのメモリで最大256,000,000レコード。 そして今、サーバーは32または64だけでなく、192 GBのメモリ（たとえばHP DL385 G6）さえも長い間サポートしており、最近リリースされたIntel Nehalem EXプロセッサは仕様に従って、プロセッサソケットあたり最大256 GBのメモリをサポートしていることを思い出します。 テラバイトのメモリはもはやフィクションの領域にないことが判明しました。 これは1つの4プロセッササーバーです。 4キロバイトページの形式でメモリを整理する古いモデルを使用すると、2億5600万ページが得られ、そのような量のメモリを操作することは、ビールジョッキのあるスイミングプールをすくうことに似ています。 そのため、メモリの大きなページの使用は遠い未来ではありませんが、どちらもほとんど存在しません。

要約すると、連想変換キャッシュは非常に重要なシステムリソースであり、その使用効率はシステムパフォーマンスに大きく影響します。 最大4 GBのメモリをサポートする32ビットシステムの事実上の標準は、4 KBの長さのページ形式のメモリの編成でした。 現在、64ビットシステムがますます使用され、メモリの量が数十または数百ギガバイトになることがある場合、このようなメモリ構成を使用すると、TLBの使用効率が大幅に低下し、結果としてシステム全体のパフォーマンスが低下する可能性があります。

「セカンドレベルアドレス変換（SLAT）」と呼ばれる新しいテクノロジーに言及することは間違いありません。 このテクノロジーは、ベンダー（AMD-Rapid Virtualization Indexing（RVI）またはNested Page Tables（NPT）、Intel-Extended Page Tables（EPT））によって異なる方法で呼び出されます。 ゲストアドレス（つまり、仮想マシン内）を物理アドレスに直接変換できます。 このような変換は、この機能がサポートされていないシステムと比較して、生産性を大幅に向上させることができます（公式には20％の増加が公式に確認され、生産性が100％増加すると言われています） そのため、仮想化にはSLATが有用であり、SLATはそれをサポートするハードウェアとソフトウェアに切り替える理由の1つです。

ただし、SLATがメモリの大きなページで動作するように設計および最適化されたことを忘れているか、単に知らない人が多くいます。 ラージページのサポートが有効になっていない場合、TLBキャッシュの効率が低下し、スモールページでSLATを使用するとパフォーマンスが20％低下する可能性があります。 また、大きなページを使用しても生産性が10〜20％向上することはありません。したがって、一般的に生産性が最大40％低下します。

上記を要約すると、ラージメモリページはパフォーマンスを最大40％向上させることができる非常に重要な要素であり、それらを使用するかどうかは修辞上の問題であることがわかります。 Large Memory Pagesは、64ビットプロセッサアーキテクチャやネットワークテクノロジーのジャンボフレームと同様に、コンピューターシステムの進化の産物です。

Yu。Luzhkovはどこにいるのでしょうか？

この記事を読むと、多くの人が合理的な疑問を抱くでしょう。なぜ、私はあらゆる種類のビッグページと連想翻訳キャッシュについて語って、木の上の苔のように広まったのですか？ 結局のところ、この記事は元々ページ共有に関するものでしたか？ 答えは非常に簡単です。大きなページを使用する場合、ページ共有は実際には機能しません。 なんで？ 小学校、ワトソン：大量のページ（2048 Kb対2 Kb）により、メモリ内で完全に同一のページを見つける可能性はほとんどゼロになります。 これは、MicrosoftとVMwareが完全に合意している数少ないケースの1つです。

community.vmware.com/message/1262016#1262016

大きなページを使用する場合の唯一の問題は、ページ共有のために、完全に同一の2 MBのメモリページを見つける必要があることです（小さい4キロバイトページと比較して）。 これの可能性ははるかに低く（ゲストOSの空白ページは例外で、「ゼロ」で完全に詰まっている）、ESXはメモリの大きなページを分離しようとしないため、ハイパーバイザーが物理的な大きなページを持つすべてのゲストページと一致する場合、TPSの使用によるメモリ節約は減少します。

要するに、ページ共有は4 KBページで効果的に機能しますが、大規模な2 MBページを使用する場合、まったく利点はありません。

空白ページ

奇妙なことに、ページ共有は、大量の未使用メモリ、つまりゼロでいっぱいのページが多数ある場合に最適に機能します。 それらは完全に同一であり、「共有」が最も簡単です。 まあ、bmp形式での「マレビッチ正方形」の圧縮のようなものです。 問題は、一部のオペレーティングシステム（特にWindows 7）が使用可能なメモリ全体を使用する傾向があることです。これはバグではなく、機能-特に、先ほど書いたWindows Vista / 7のSuperFetchです。 したがって、これはページ共有テクノロジーの有効性の低下にもつながります。

まとめ

• 現在、プロセッサでは大容量（2 MB）ページのメモリ（大容量メモリページ）がサポートされています。 AMDはOpteronプロセッサの最新世代で大きなメモリページをサポートしていますが、Intelは新しいNehalemプロセッサでそれらのサポートを実装しています。 つまり、まもなく一般に受け入れられる標準になります。
  
  -ページ共有は、ほとんどゼロの効率でメモリの大きなページを持つシステムで動作します。 4キロバイトのページが互いに同一であることが多い場合、2 MBのページサイズでは、完全に同一のページを見つけることはほとんど不可能です。 繰り返しますが、これはMicrosoftとVMwareの意見が一致する数少ないポイントの1つです。
  
  -したがって、ページ共有は4キロバイトのページでのみ効果的に機能します。 ただし、4キロバイトのページを使用すると、TLBのパフォーマンスが低下し、SLATを使用できなくなり、システムパフォーマンスが最大40％低下します。
  
  -Windows Server 2008/2008 R2およびWindows Vista / 7では、メモリの大きなページのサポートがデフォルトで有効になっています。
  
  -Hyper-V R2では、ハイパーバイザーレベルでラージページがサポートされています。
• メモリの大きなページを忘れた場合でも、最新のオペレーティングシステムが利用可能なすべてのメモリ（SuperFetch）を使用しようとしているため、ページ共有の効率が低下します。
• 作業ページ共有の準備プロセスには、メモリのすべてのページのハッシュ、テーブルへのハッシュの保存、ビット単位の比較が含まれます。 このプロセスは長く、リソースを大量に消費し、数時間かかる場合があります。
• ページ共有は、メ​​モリを動的に割り当てるための最も効率的な方法ではありません。 つまり、仮想マシンに緊急にメモリを追加する必要がある場合、または1つの仮想マシンに空きメモリがあり、別の仮想マシンに割り当てる必要がある場合、ページ共有はあまり役に立ちません。

このすべてから、最新の機器とオペレーティングシステムを使用したページ共有技術は、せいぜい役に立たず、有害でさえあります。生産性を低下させ、鉄とOSの新機能の使用を許可しません。



次の記事では、「メモリオーバーコミットメント」のテクノロジーに関する議論を続けます。今回は、セカンドレベルページングについて説明します。