ESX 4.1での透過的なページ共有-昨年の記事の続き

偶然、数週間前、昨年の透明なページ共有に関するSystem32の関連記事を偶然見つけました。VCAP-DCAの準備スケジュールを中断し、vSphereの完全に未知のメモリ管理テクノロジーに没頭するようになりました。正確-TPSで。 System32の同僚は、メモリを操作する一般的な原則であるTPS操作アルゴリズムの概要を非常に知的に説明しましたが、同時にまったく正しい結論を下しませんでした。 同じ記事によると、ラージページを使用する場合、TPSテクノロジーが機能しないという事実にもかかわらず、esxtopの高いSHRD値について誰も回答しなかったコメントの質問にさらに当惑しました。 一般に、美しい理論と実践の間には重大な矛盾が見つかりました。



Vmwareフォーラムで4〜5日間掘り下げ、Wiki、 西洋の ブロガーを読んだ後、頭の中に何かがあり、コメントからの質問に答えることができました。 どういうわけか私の新鮮な知識を合理化するために、英語のブログでこのトピックに関するいくつかの記事を書くことにしました。 また、このトピックに関する新しい記事のためにHabrを提供しましたが、驚いたことに、2010年以来、私は新しいものを何も発見していません。 したがって、Habrを常に読み、コメントに積極的に参加して、トランスペアレントページ共有に関する独自の記事と、Nehalem / Opteronファミリーのプロセッサを搭載し、ESX（i）4.1がインストールされているシステムでの使用のニュアンスを翻訳する機会を得るために決めました。



記事を長くしすぎる気はないので、（特にvSphere管理者の場合）最初に記事を読んで、最初に提供したリンクを読むことを強くお勧めします。 しかし、それでも、ささいなことを繰り返します。



TPSは何のためにあるのですか？

答えは非常にありふれたものです。RAMを節約し、仮想マシンにホスト自体にあるよりも多くのメモリを表示するため、より高いレベルの統合を提供します。



彼はどのように働いていますか？

歴史的に、x86システムでは、すべてのメモリは4 KBブロック、いわゆるページに分割されています。 同じOSを備えた同じESXホストで20台の仮想マシン（VM）を実行している場合、これらのVMには多くの同一のメモリページがあることが容易に想像できます。 ESXホスト上の同一のページを見つけるために、TPSプロセスが60分の周期で起動されます。 メモリ内のすべてのページを完全にスキャンし、各ページのハッシュを計算します。 すべてのハッシュが1つのテーブルに追加され、カーネルによって一致がチェックされます。 ハッシュ衝突と呼ばれる問題を回避するために、同じハッシュを検出すると、カーネルは対応するページをビットごとにチェックします。 そして、それらが100％同一であることを確認した後にのみ、カーネルはページの1つのコピーをメモリに残し、削除されたページへのすべての呼び出しは最初のコピーにリダイレクトされます。 VMのいずれかがこのページの何かを変更することを決定した場合、ESXは元のページの別のコピーを作成し、VMが既にそれを使用できるようにし、変更のリクエストを送信します。 したがって、Vmwareの用語では、このタイプのページはコピーオンライト（COW）と呼ばれます。 時には数百ギガバイトのRAMを搭載した最新のサーバーでメモリをスキャンするプロセスには非常に長い時間がかかる場合があるため、すぐに結果を期待することはできません。



NUMAおよびTPS

NUMAは、プロセッサ間でメモリアクセスを共有するためのかなり興味深い技術です。 幸いなことに、ESXの最新バージョンは十分にスマートであり、効率的なNUMAシステムではTPSはNUMAノード内でのみ動作することを知っています。 原則として、ESXでVMkernel.Boot.sharePerNodeの値を調整すると、個々のNUMAノードではなく、メモリ全体内のページをTPSで比較できます。 この場合、より高いSHAREDメモリ値を達成できることは明らかですが、重大なパフォーマンス低下の可能性を考慮する必要があります。 たとえば、ESXホストに4つのXeon 5560プロセッサ、つまり4つのNUMAノードがあり、それぞれにメモリページの同一のコピーが含まれているとします。 TPSが最初のノードに1つのコピーを残し、残りの3つを削除する場合、これらの3つのノードで動作するVMのいずれかが目的のメモリページを必要とするたびに、3つのプロセッサがローカルおよび非常に高速なメモリバスを介してアクセスする必要がないことを意味しますしかし、一般的で遅い。 そのようなページが多いほど、共有バスに残る帯域幅が少なくなるため、仮想マシンのパフォーマンスがさらに低下します。



ゼロページ

vSphere 4.0で導入された優れた新機能の1つは、ゼロページ認識でした。 原則として、これは通常のページであり、最初から最後までゼロで埋められます。 Windows VMがオンになるたびに、すべてのメモリがリセットされます。これにより、OSは利用可能なメモリの正確なサイズを判断できます。 ESXは仮想マシンでそのようなページを即座に検出でき、ゼロページに物理メモリを割り当ててTPS中にそれらを削除する無用なプロセスの代わりに、ESXはそのようなページをすべて単一のゼロページに即座にリダイレクトします。 esxtopを実行し、新しく起動されたVMのメモリ値を確認すると、ZERO値とSHRD値がほぼ同じであることがわかります。







ただし、この新しいすばらしい機能であるESX 4.0（およびそれ以前）は、EPT（Intel）またはRVI（AMD）テクノロジーを搭載したプロセッサーでのみ使用できることに注意してください。 KingstonのWebサイトには、このテーマに関する優れた記事が2 つあります（ パート1 、 パート2 ）。 要するに、新しいプロセッサで物理メモリを割り当てずにゼロページを認識する方法を示して示しますが、古いプロセッサでは物理メモリが割り当てられ、TPSが完全に満たされた場合にのみ使用済み物理メモリの削減が開始されます。 通常のvSphereファームでは、これは原則的に重要ではありませんが、VDIインフラストラクチャでは、数百台の仮想マシンを同時に起動できるため、これは便利です。



ゼロページのTPSの機能。

1 Windows OSには、「ファイルシステムキャッシング」と呼ばれる技術があります（名前と定義の翻訳に誤りがある場合は、申し訳ありません）。 MSの定義を使用すると、「ファイルシステムキャッシングは、最近使用した情報をすばやくアクセスするために保存するメモリ領域です」と言えます。 このキャッシュはカーネルのアドレス空間にあるため、32ビットシステムでは、サイズは1ギガバイトに制限されています。 ただし、64ビットシステムでは、そのサイズは1テラバイトに達します（ 証明 ）。 原則として、このテクノロジーはパフォーマンスに非常に役立ちますが、仮想マシンがあり、大きなページ（2メガバイト）がゼロの場合、esxtopのSHRD値はゼロになります。

上記のスクリーンショットは、Windows 2008 R2仮想マシンを起動した直後のesxtopの値を示していましたが、30分後にesxtopが示したものは次のとおりです。







この仮想マシンのタスクマネージャーでは、空きメモリがどれだけあるか（ゼロ）を簡単に確認できます。







残念ながら、これがどうしてこうなるのかという理由には至りませんでしたが、ファイルシステムのキャッシングはメモリへの連続的な書き込みとしてではなく、そのさまざまな領域に発生するようです。

2 。 仮想マシンのメモリページのリセットは、オンになっている場合にのみ発生します。 標準の再起動では、ページはゼロにリセットされません。



大きなページ

ESXのカーネルが使用するラージページは2メガバイトです。 物理メモリで2つの同一の大きなページが見つかる可能性は一般にほぼゼロであるため、ESXはそれらを比較しようとさえしません。 EPT / RVIで新しいプロセッサを使用する場合、これはホストが可能な限り大きなページを積極的に使用しようとすることを意味します。 このようなホストのSHRD値を見ると、その低い値に不愉快な驚きを覚えますが、それでもかなりの量です。 70 GBが割り当てられた実稼働ホストでは、約4 GBにSHRDがありました。 ちなみに、これは記事のコメントの中で最も興味深い質問の1つであり、このトピックから私の関心が始まりました。 これで、これらのページがゼロページであることがわかり、無知と当て推量でひどく苦しめられました。

この低いレートは、TPSがESX 4.0ホストでの動作を停止したと人々が判断したという単純な理由により、当初Vmwareフォーラムで激しい議論を巻き起こしました。 Vmwareはこれについての説明を投稿せざるを得ませんでした。

それでも、ホストがラージページをアクティブに使用している場合でも、TPSはまったくスリープしません。 彼はまた、同一の4 kBページのメモリを整然とスキャンし、意思があれば削除できます。 重複するページを見つけるとすぐに、ブックマーク（ヒント）をそこに置きます。 ESXメモリで使用される値が94％に達すると、ホストはすぐに大きなページを小さなページに分割し、時間のスキャンを無駄にしません（TPSは既にブックマークを設定しています）、再び同じページの削除を開始します。 まだこのポイントに達していない場合は、同じesxtopの[COWH（コピーオンライトヒント）]フィールドで、大きなページを小さなページに分割した後の節約量を確認できます。







繰り返しになりますが、古いプロセッサと新しいプロセッサの間で大きなページを扱う際の違いに注意を喚起したいと思います。 Vmware自体には、バージョン3.5以降のラージページのサポートが含まれています。 VMwareの「 ラージページパフォーマンス 」ドキュメントによると、仮想マシンのOSがラージページを使用する場合、ESXホストは物理メモリにラージページをこのVM専用に割り当てます。 ただし、同じ仮想マシンがEPT / RVIプロセッサを搭載したESXホストで実行されている場合、VMの大規模ページのサポートに関係なく、ESXは物理メモリ内の大規模ページを使用します。これは、同じドキュメントで知られているように、プロセッサパフォーマンスの大幅な向上につながります。

興味深いことに、Windows 2008R2の90％を回転させる古いプロセッサとESX 4.1を備えたホストのペアでは、非常に高いSHRDが見られます。 残念ながら、古いプロセッサでのラージページのサポートの仕組みに関する詳細なドキュメントは見つかりませんでした。どのような条件下、どのOSなどでラージページが使用されるかです。 だから私にとってはまだ空白の場所です。 近い将来、古いプロセッサを搭載したESX 4.1ホストで10個のWindows 2008 R2を実行し、メモリ値を確認しようとします。

多かれ少なかれこれだけを学んだとき、私は困惑しました-Nehalemプロセッサを搭載したホストで大きなページのサポートを手動でオフにするとどうなりますか？ 保存されたメモリはどれだけ表示され、パフォーマンスはどれだけ低下しますか？ 「まあ、長い間考えなければならないこと-あなたはそれをしなければなりません」と私は考え、私たちの本番ホストの1つで大きなページのサポートをオフにしました。 当初、このホストには70 GBの割り当てられたメモリと4 GBの共有メモリがありました（ええ、そうです、これらはゼロページです）。 平均プロセッサ使用率が25％を超えることはありませんでした。 大きなページをオフにした2時間後、共有メモリの値は32 GBに増加し、プロセッサの負荷は同じレベルのままでした。 それから4週間が経ちましたが、パフォーマンスの低下に関する苦情は一度もありません。



そして最後に、私の結論

同僚と情報を共有した後、彼らは「ホストが必要に応じてそれらを無効にする場合、大きなページのサポートをオフにすることで一体何をしますか？」と私に尋ねました。 そして、すぐに答えを知っていました-大きなページのサポートがデフォルトでオンになっていると、TPSでメモリを節約できる可能性を十分に確認できず、ESXホストでの追加のVM配置を正しく計画できず、統合のレベルを予測できません。 vSphereファームのリソースを管理するという点では盲目です。 しかし、ダンカンエッピングなどのvSphereの第一人者は、「心配する必要はありませんが、TPSは必要なときに機能し、同時にパフォーマンスが大幅に向上します」と保証しました。 数日後、私は彼と仮想化の世界の他の当局との間で素晴らしい議論を見つけました。それは、大きなページをオフにするという私の決定の正しさを確認しただけです。 COWH値を使用してリソースの使用を計画できると言う人もいますが、何らかの理由でこの値が常に正しいとは限りません。 このスクリーンショットは、3週間大きなページが無効になっているホストで実行されているWindows 2003サーバーの1つの値を示しています。SHRD値とCOWH値は非常に異なっています。







1週間前、別の4つのホスト、別のファームで大きなページを無効にしましたが、パフォーマンスの低下に気付きませんでした。 ただし、これはすべて個別であり、そのような決定を行う際には、ファーム、リソース、仮想マシンの詳細を考慮する必要があります。



幸運にもこの記事が面白いと思えば、古い世代と新しい世代のプロセッサ間のメモリ管理の違いに関する別の記事を翻訳したいと思います。