VMware vSphere での VM パフォーマンス分析。 パート 2: 記憶

パート 1. CPU について

この記事では、vSphere のランダム アクセス メモリ (RAM) のパフォーマンス カウンターについて説明します。
メモリの場合、プロセッサの場合よりもすべてがより明確になるようです。VM にパフォーマンスの問題がある場合、それに気付かないのは困難です。 しかし、それらが現れた場合、それらに対処することははるかに困難です。 しかし、まず最初に。

いくつかの説

仮想マシンの RAM は、VM が実行されているサーバーのメモリから取得されます。 それは非常に明白です:)。 サーバの RAM がすべての人にとって十分ではない場合、ESXi はメモリ再利用技術を使用して RAM の消費を最適化します。 そうしないと、VM オペレーティング システムが RAM アクセス エラーでクラッシュします。

ESXi でどのテクニックを使用するかは、RAM の負荷に応じて決まります。

メモリの状態

ボーダー

活動

ハイ

minFree の 400%

上限に達すると、大きなメモリ ページが小さなメモリ ページに分割されます (TPS は標準モードで動作します)。

クリア

minFree の 100%

大きなメモリ ページが小さなメモリ ページに分割され、TPS が強制的に動作します。

ソフト

minFree の 64%

TPS+バルーン

ハード

minFree の 32%

TPS + 圧縮 + スワップ

ロー

minFree の 16%

圧縮 + スワップ + ブロック

ソース

minFree は、ハイパーバイザーが動作するために必要な RAM です。

ESXi 4.1 より前では、minFree はデフォルトで固定されており、サーバーの RAM の 6% でした (この割合は ESXi の Mem.MinFreePct オプションで変更できます)。 後のバージョンでは、サーバーのメモリ サイズが増加したため、minFree は固定パーセンテージではなくホスト メモリの量に基づいて計算されるようになりました。

minFree (デフォルト) 値は次のように計算されます。

minFree 用に予約されているメモリの割合

メモリ範囲

6%

0～4GB

4%

4～12GB

2%

12～28GB

1%

メモリ残量

ソース

たとえば、128 GB の RAM を搭載したサーバーの場合、MinFree 値は次のようになります。
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12MB = 1,88GB
実際の値はサーバーと RAM に応じて数百 MB 異なる場合があります。

minFree 用に予約されているメモリの割合

メモリ範囲

128 GB の価値

6%

0～4GB

245,76MB

4%

4～12GB

327,68MB

2%

12～28GB

327,68MB

1%

メモリ残量（100GB）

1024MB

通常、生産的なスタンドでは、High 状態のみが正常とみなされます。 テストおよび開発ベンチの場合、クリア/ソフト状態が許容される場合があります。 ホスト上の RAM が MinFree の 64% 未満の場合、ホスト上で実行されている VM には明らかにパフォーマンスの問題があります。

各状態では、VM のパフォーマンスに実質的に影響を与えない TPS から始まり、スワッピングで終わる特定のメモリ再利用技術が適用されます。 それらについて詳しくお話します。

透過的ページ共有 (TPS)。 TPS は、大まかに言えば、サーバー上の仮想マシンのメモリ ページの重複排除です。

ESXi は、ページのハッシュ合計を数えて比較することによって仮想マシン RAM の同一のページを探し、重複したページを削除して、サーバーの物理メモリ内の同じページへのリンクに置き換えます。 その結果、物理メモリの消費量が削減され、パフォーマンスをほとんどまたはまったく低下させることなく、メモリのオーバーサブスクリプションをある程度実現できます。

ソース

このメカニズムは、4 KB のメモリ ページ (小さいページ) でのみ機能します。 ハイパーバイザーは 2 MB のページ (大きなページ) の重複排除を試みません。このサイズの同一のページが見つかる可能性は高くありません。

デフォルトでは、ESXi は大きなページにメモリを割り当てます。 大きなページを小さなページに分割することは、High 状態のしきい値に達すると開始され、Clear 状態に達すると強制的に行われます (ハイパーバイザー状態テーブルを参照)。

ホスト RAM がいっぱいになるのを待たずに TPS が動作を開始するようにするには、ESXi の詳細オプションで値を設定する必要があります。 「Mem.AllocGuestLargePage」 0 に設定します (デフォルトは 1)。 その後、仮想マシンへの大きなメモリ ページの割り当てが無効になります。

2014 年 XNUMX 月以降、理論上、ある VM から別の VM の RAM へのアクセスを許可する脆弱性が発見されたため、ESXi のすべてのリリースでは VM 間の TPS がデフォルトで無効になっています。 詳細はこちら。 TPS の脆弱性を悪用する実際の実装に関する情報は見つかりませんでした。

詳細オプションで制御される TPS ポリシー 「Mem.ShareForceSalting」 ESXi の場合:
0 - VM 間 TPS。 TPS は、さまざまな VM のページに対して機能します。
1 – VMX で同じ「sched.mem.pshare.salt」値を持つ VM の TPS。
2 (デフォルト) - VM 内 TPS。 TPS は VM 内のページに対して機能します。

テストベンチでラージ ページをオフにして、Inter-VM TPS をオンにすることは間違いなく合理的です。 同種のVMを多数搭載するスタンドにも使用できます。 たとえば、VDI を備えたスタンドでは、物理メモリの節約が数十パーセントに達する可能性があります。

記憶が膨らむ。 バルーニングは、VM オペレーティング システムにとって、TPS ほど無害で透過的な技術ではなくなりました。 ただし、適切なアプリケーションを使用すれば、Ballooning を使用して作業することもできます。

Vmware Tools とともに、Balloon Driver (別名 vmmemctl) と呼ばれる特別なドライバーが VM にインストールされます。 ハイパーバイザーが物理メモリを使い果たし始め、ソフト状態になると、ESXi はこのバルーン ドライバを通じて未使用の RAM を再利用するように VM に要求します。 次に、ドライバーはオペレーティング システム レベルで動作し、そこに空きメモリを要求します。 ハイパーバイザーは、Balloon Driver が物理メモリのどのページを占有しているかを確認し、仮想マシンからメモリを取得してホストに返します。 OSレベルではBalloon Driverがメモリを占有しているため、OSの動作に問題はありません。 デフォルトでは、Balloon Driver は VM メモリの最大 65% を占有する可能性があります。

VMware Tools が VM にインストールされていない場合、またはバルーニングが無効になっている場合 (お勧めしませんが、 KB:)、ハイパーバイザーは、より厳格なメモリ削除手法に直ちに切り替えます。 結論: VMware Tools が VM 上にあることを確認してください。

OSからVMware Tools経由でBalloon Driverの動作確認が可能.

メモリの圧縮。 この手法は、ESXi がハード状態に達したときに使用されます。 名前が示すように、ESXi は RAM の 4KB ページを 2KB に縮小し、サーバーの物理メモリ上のスペースを解放しようとします。 この手法では、最初にページを解凍する必要があるため、VM RAM ページのコンテンツへのアクセス時間が大幅に増加します。 すべてのページを圧縮できない場合があり、プロセス自体に時間がかかります。 したがって、この手法は実際にはあまり効果的ではありません。

メモリの交換。 短いメモリ圧縮フェーズの後、ESXi はほぼ必然的に (VM が他のホストに移動していない場合、または電源がオフになっていない場合)、スワッピングに切り替わります。 また、メモリがほとんど残っていない場合 (低状態)、ハイパーバイザは VM へのメモリ ページの割り当ても停止するため、VM のゲスト OS で問題が発生する可能性があります。

スワッピングの仕組みは次のとおりです。 仮想マシンをオンにすると、.vswp 拡張子を持つファイルが仮想マシン用に作成されます。 これは、VM の予約されていない RAM と同じサイズです。つまり、構成されたメモリと予約されたメモリの差です。 スワッピングの実行中、ESXi は仮想マシンのメモリ ページをこのファイルにアンロードし、サーバの物理メモリの代わりにそのファイルの操作を開始します。 もちろん、そのような「動作可能な」メモリは、たとえ .vswp が高速ストレージ上にあったとしても、実際のメモリよりも数桁遅いです。

バルーニングとは異なり、スワッピングでは、未使用のページが VM から取得されると、VM 内の OS またはアプリケーションによってアクティブに使用されているページをディスクに移動できます。 その結果、VM のパフォーマンスがフリーズ点まで低下します。 VM は正式に動作し、少なくとも OS から適切に無効にすることができます。 辛抱強いなら😉

VM がスワップに移行した場合、これは異常な状況であるため、可能であれば回避するのが最善です。

主要な VM メモリ パフォーマンス カウンター

それで本題に入りました。 VM のメモリの状態を監視するために、次のカウンターがあります。

アクティブ — 前回の測定期間に VM がアクセスした RAM の量 (KB) を示します。

使用法 - アクティブと同じですが、VM の構成された RAM の割合として表されます。 次の式を使用して計算されます: アクティブ ÷ 仮想マシンの構成メモリ サイズ。
高使用率とアクティブは、それぞれ VM のパフォーマンスの問題を示すものではありません。 VM がメモリを積極的に使用する (少なくともアクセスできる) 場合、これはメモリが不足していることを意味するものではありません。 むしろ、これは OS で何が起こっているかを確認する機会です。
VM には標準のメモリ使用量アラームがあります。

共有 - TPS を使用して重複排除された VM RAM の量 (VM 内または VM 間)。

付与 - VM に割り当てられた物理ホスト メモリの量 (KB)。 共有も含まれます。

消費された (許可 - 共有) - VM がホストから消費する物理メモリの量 (KB)。 共有は含まれません。

VM メモリの一部がホストの物理メモリからではなくスワップ ファイルから与えられる場合、またはメモリがバルーン ドライバーを通じて VM から取得される場合、この量は付与および消費では考慮されません。
付与値と消費値が高いのは完全に正常です。 オペレーティング システムは徐々にハイパーバイザーからメモリを奪い、返さなくなります。 アクティブに実行されている VM では、時間の経過とともに、これらのカウンターの値が構成されたメモリの量に近づき、そこに留まります。

設定作業無し — VM RAM の量 (KB)。ゼロが含まれます。 このようなメモリはハイパーバイザーによって空きとみなされ、他の仮想マシンに割り当てることができます。 ゲスト OS がゼロ化されたメモリに何かを書き込むと、消費状態になり、元に戻りません。

予約済みオーバーヘッド — VM 操作用にハイパーバイザーによって予約された VM RAM の量 (KB)。 これは少量ですが、ホスト上で使用できる必要があります。そうでない場合、VM は起動しません。

バルーン — Balloon Driver を使用して VM から占有された RAM の量 (KB)。

圧縮された - 圧縮された RAM の量 (KB)。

スワップ - サーバー上の物理メモリ不足によりディスクに移動された RAM の量 (KB)。
バルーンおよびその他のメモリ再利用技術のカウンターはゼロです。

150 GB の RAM を搭載し、正常に動作している VM のメモリ カウンターのグラフは次のようになります。

以下のグラフでは、VM に明らかな問題があります。 グラフの下で、この VM では、RAM を操作するための説明されたすべてのテクニックが使用されたことがわかります。 この VM のバルーンは、消費されたバルーンよりもはるかに大きくなります。 実際、VM は生きているというよりも死んでいる状態です。

ESXTOP

CPU と同様に、ホスト上の状況やそのダイナミクスを最大 2 秒間隔で迅速に評価したい場合は、ESXTOP を使用する必要があります。

Memory による ESXTOP 画面は「m」キーで呼び出され、次のようになります (フィールド B、D、H、J、K、L、O が選択されています)。

以下のパラメータが興味深いでしょう。

平均オーバーコミットメモリ - 1、5、15 分間のホスト上のメモリ オーバーサブスクリプションの平均値。 ゼロを超えている場合は、何が起こっているかを確認する機会ですが、必ずしも問題を示しているわけではありません。

ラインで PMEM/MB и VMKMEM/MB - サーバーの物理メモリと VMkernel が使用できるメモリに関する情報。 ここで興味深いことに、minfree の値 (MB 単位)、メモリ内のホストの状態 (この場合は高) がわかります。

列をなして NUMA/MB NUMA ノード (ソケット) ごとの RAM の分布を確認できます。 この例では、分布は不均一であり、原理的にはあまり良好ではありません。

以下は、メモリ再利用技術に関する一般的なサーバー統計です。

PSARE/MB は TPS 統計です。

スワップ/MB — スワップ使用統計。

ZIP/MB — メモリページ圧縮統計。

MEMCTL/MB — バルーンドライバーの使用統計。

個々の VM については、次の情報が必要となる場合があります。 視聴者を混乱させないように、VM 名は隠しました :)。 ESXTOP メトリックが vSphere のカウンタに類似している場合は、対応するカウンタを示します。

メムズ — VM 上に構成されたメモリの量 (MB)。
MEMSZ = GRANT + MCTLSZ + SWCUR + 未処理。

GRANT — MB に付与されました。

TCHD — MBで活躍中。

MCTL? - Balloon Driver が VM にインストールされているかどうか。

MCTLSZ — MB へのバルーン。

MCTLGT — ESXi がバルーン ドライバー (Memctl ターゲット) 経由で VM から取得したい RAM の量 (MB)。

MCTLMAX - ESXi がバルーン ドライバーを通じて VM から取得できる RAM の最大量 (MB)。

SWCUR — スワップ ファイルから VM に割り当てられている現在の RAM 量 (MB)。

S.W.G.T. - ESXi がスワップ ファイル (スワップ ターゲット) から VM に提供したい RAM の量 (MB)。

また、ESXTOP を通じて、VM の NUMA トポロジに関する詳細情報を確認できます。 これを行うには、フィールド D、G を選択します。

NHN – VM が配置されている NUMA ノード。 ここでは、XNUMX つの NUMA ノードに収まらないワイド vm にすぐに気づくことができます。

NRMEM - VM がリモート NUMA ノードから取得するメモリのメガバイト数。

NLMEM - VM がローカル NUMA ノードから取得するメモリのメガバイト数。

N%L – ローカル NUMA ノード上の VM メモリの割合 (80% 未満の場合、パフォーマンスの問題が発生する可能性があります)。

ハイパーバイザー上のメモリ

ハイパーバイザーの CPU カウンターが通常は特に重要ではない場合、メモリに関しては状況が逆転します。 VM 上の高いメモリ使用量が必ずしもパフォーマンスの問題を示しているわけではありませんが、ハイパーバイザー上の高いメモリ使用量はメモリ管理手法を引き起こし、VM のパフォーマンス上の問題を引き起こします。 VM がスワップ状態にならないように、ホスト メモリ使用量アラームを監視する必要があります。

スワップを解除する

VM がスワップ状態にある場合、そのパフォーマンスは大幅に低下します。 バルーニングと圧縮の痕跡は、ホストに空き RAM が現れるとすぐに消えますが、仮想マシンはスワップからサーバー RAM に急いで戻りません。
ESXi 6.0 より前は、VM をスワップから解除する唯一の信頼できる迅速な方法は、再起動することでした (より正確には、コンテナの電源をオフ/オンにします)。 ESXi 6.0 以降、完全に公式ではありませんが、スワップから VM を削除する有効かつ信頼できる方法が登場しました。 あるカンファレンスで、CPU スケジューラを担当する VMware エンジニアの XNUMX 人と話すことができました。 彼は、この方法が非常に効果的で安全であることを確認しました。 私たちの経験上、これでも問題はありませんでした。

スワップから VM を削除するための実際のコマンド 説明した ダンカン・エッピング。 詳細な説明は繰り返さないので、使用例を示すだけです。 スクリーンショットでわかるように、指定されたコマンドの実行後しばらくすると、VM 上でスワップが消えます。

ESXi メモリ管理のヒント

最後に、RAM による VM パフォーマンスの問題を回避するのに役立つヒントをいくつか紹介します。

• 実稼働クラスターでのメモリーのオーバーサブスクリプションを回避します。 DRS (および管理者) が操作できる余地があり、移行中に VM がスワップ状態にならないように、クラスター内に常に約 20 ～ 30% の空きメモリがあることが望ましいです。 また、耐障害性のためのマージンも忘れないでください。 XNUMX 台のサーバーに障害が発生し、HA を使用して VM が再起動されると、一部のマシンもスワップ状態になるのは不快です。
• 高度に統合されたインフラストラクチャでは、ホスト メモリの半分を超える VM を作成しないようにしてください。 これにより、DRS が問題なくクラスタ サーバー全体に仮想マシンを分散できるようになります。 もちろん、このルールは普遍的ではありません:)。
• ホストのメモリ使用量アラームを監視します。
• VM に VMware Tools を忘れずにインストールし、バルーニングをオフにしないでください。
• VDI およびテスト環境では、Inter-VM TPS を有効にし、ラージ ページを無効にすることを検討してください。
• VM でパフォーマンスの問題が発生している場合は、リモート NUMA ノードのメモリを使用しているかどうかを確認してください。
• できるだけ早く VM をスワップから解放してください。 特に、VM がスワップ状態にある場合、明らかな理由により、ストレージ システムに影響が生じます。

RAM については以上です。 さらに詳しく知りたい方は以下の関連記事をどうぞ。 次の記事は storadzh について取り上げます。

便利なリンク集http://www.yellow-bricks.com/2015/03/02/what-happens-at-which-vsphere-memory-state/
http://www.yellow-bricks.com/2013/06/14/how-does-mem-minfreepct-work-with-vsphere-5-0-and-up/
https://www.vladan.fr/vmware-transparent-page-sharing-tps-explained/
http://www.yellow-bricks.com/2016/06/02/memory-pages-swapped-can-unswap/
https://kb.vmware.com/s/article/1002586
https://www.vladan.fr/what-is-vmware-memory-ballooning/
https://kb.vmware.com/s/article/2080735
https://kb.vmware.com/s/article/2017642
https://labs.vmware.com/vmtj/vmware-esx-memory-resource-management-swap
https://blogs.vmware.com/vsphere/2013/10/understanding-vsphere-active-memory.html
https://www.vmware.com/support/developer/converter-sdk/conv51_apireference/memory_counters.html
https://docs.vmware.com/en/VMware-vSphere/6.5/vsphere-esxi-vcenter-server-65-monitoring-performance-guide.pdf

出所： habr.com