vSphereの教育-RAMが多すぎる*とVMを構成することの欠点は何ですか？
VMwareのメモリ管理は、トリッキーなバランシング行為のようです。クラスターRAM、リソースプール、VMwareの管理手法（TPS、バルーニング、ホストスワッピング）、ゲスト内RAM使用率、スワッピング、予約、共有、制限）には、多くの変数があります。
クライアントが専用のvSphereクラスターリソースを使用している状況です。 ただし、物理マシン上にあるかのように仮想マシンを構成しています。次に、これは標準のVM =ビルドには4つのvCPUと16GB以上のRAMがある場合があります。私は小規模（1 vCPU、最小RAM）から始めて、実際の使用状況をチェックし、必要に応じて調整しています。残念ながら、多くのベンダーの要件や仮想化に慣れていない人々必要以上のリソースをリクエストします...この決定の影響を数値化することに興味があります。
「問題」クラスターからのいくつかの例。
リソースプールの概要-ほぼ4：1でオーバーコミットされています。バルーンRAMの量が多いことに注意してください。 
リソースの割り当て-最悪の場合の割り当ての列は、これらのVMが、構成されたRAM制約された条件下で）の50％未満にアクセスできることを示しています。- 
リアルタイムメモリ使用率グラフの上部VM。4つのvCPUと64GB RAMが割り当てられています。平均は9GB使用。
同じVMの概要 
VSphere環境でリソース（特にRAM）をオーバーコミットおよびオーバー構成することの欠点は何ですか？
VMがより少ないRAMで実行できると仮定すると、より多くのRAM actually need）で仮想マシンを構成するオーバーヘッドがあると言っても過言ではありませんか？
"if a VMには16GBのRAMが割り当てられていますが、4GBしか使用していませんが、問題は何ですか。 ?? "？たとえば、 VMは物理ハードウェアと同じではないことをお客様に説明する必要がありますか？
RAM使用状況を測定するためにどの特定のメトリックを使用する必要がありますか。「アクティブ」と時間のピークを追跡しますか？「消費」を監視していますか？
更新：私が使用したvCenter Operations Managerこの環境のプロファイルを作成し、上記のクラスター統計の詳細を取得します。確実にオーバーコミットされていますが、VMは実際には so で過剰に構成されていますRAM実際の（小さな）メモリフットプリントはクラスタでメモリの競合を示していません） /ホストレベル...
私のポイントは、VMは実際にはOSレベルのキャッシュ用に少しのバッファーを備えた適切なサイズである必要があるということです。無知またはベンダーの「要件」からのオーバーコミットここに示す状況につながります。パフォーマンスに影響があるため、メモリのバルーニングはすべての場合に悪いようです。したがって、適切なサイズ設定はこれを防ぐのに役立ちます。
Update 2：これらのVMの一部は、次のものでクラッシュし始めています：
kernel:BUG: soft lockup - CPU#1 stuck for 71s!
VMwareはこれを 大量のメモリのオーバーコミットの症状 と説明しています。だから私はそれが質問に答えると思います。
vCops「特大仮想マシン」レポート... 
vCops "Reclaimable Waste"グラフ...
vSphereのメモリ管理はかなりまともですが、使用される用語は多くの混乱を引き起こします。
一般に、メモリのオーバーコミットは、まさにこのタイプの問題を引き起こすため、回避する必要があります。しかし、それが避けられない時があるので、事前に警告されます！
VSphere環境でリソース（特にRAM）をオーバーコミットおよび過剰構成することの欠点は何ですか？
リソースを過剰に使用することの主な欠点は、競合が発生した場合、ホストはそれぞれのVMを提供するために、舞台裏でバルーン、スワップ、またはインテリジェントにスケジュール/重複解除を余儀なくされることです。 RAM必要です。
バルーニングの場合、vSphereは選択したVM内でRAMの「バルーン」を膨らませ、それを必要とするゲストにそのバルーニングされたRAMを与えます。これはそうではありません。 tは「悪い」-VMは互いのRAMを盗んでいるので、ディスクの交換は行われません-しかし、これらがVMの分析に依存している場合、アラートの誤発火や歪んだメトリックにつながる可能性がありますRAM RAMは "バルーン"としてマークされないため、OSによって "使用中"とされるだけです。
VSphereで使用できるもう1つの機能は、透過的なページ共有（TPS）です。これは、本質的にRAM重複除外です。vSphereは、割り当てられたすべてのRAMを定期的にスキャンし、重複するページを探します。見つかった場合、重複ページを重複排除して解放します。
詳細な説明が必要な場合は、 vSphereのメモリ管理ホワイトペーパー（PDF） -特に「ESXiでのメモリの再利用」（8ページ）をご覧ください。
VMがより少ないRAMで実行できると仮定すると、必要以上のRAMを使用して仮想マシンを構成するとオーバーヘッドが発生することになりますか？
目に見えるオーバーヘッドはありません。100GBのRAMを16 GBのホストに割り当てることができます（ただし、これはにする必要があることを意味しません、上記の理由）。
すべてのVMで使用中の合計メモリは、グラフに示されている「アクティブ」曲線です。もちろん、オーバーコミットする量を計算するときは、その数値だけに依存するべきではありませんが、過去のメトリックがある場合は、実際の使用量に基づいて分析して計算することができます。
「アクティブ」と「消費」の違いRAMは、この VMWareコミュニティスレッド で説明されています。
"の場合、VMに16GBのRAMが割り当てられていますが、4GBしか使用していません。問題?? "？たとえば、顧客を教育する必要がありますか？
これに対する簡単な答えはyesです。顧客は、常にに関係なく、ベストプラクティスで教育を受ける必要があります。自由に使えるツール。
お客様は、欲しいではなく、使用するに従ってVMのサイズを決定するように教育する必要があります。多くの場合、これまで毎日2 GBでぶつかっていたとしても、人々は16 GBのRAMを必要とする可能性があるため、VMを過剰に指定します。 vSphere管理者は、それらに挑戦し、実際にRAM割り当てられている必要があるかどうかを尋ねます。
つまり、vSphereのメモリ管理と慎重に制御されたオーバーコミット制限を組み合わせる場合、実際に問題が発生することはめったになく、長期間RAMが不足する可能性は比較的低いです。 。
これに加えて、自動化されたvMotion（VMwareによって Distributed Resource Scheduling と呼ばれます）は基本的にVMのロードバランサーです-1つのVMがリソースを独占する場合、DRSは、クラスターのリソースを最大限に活用するためにVMを移行する必要があります。
RAM使用状況を測定するためにどの特定のメトリックを使用する必要があります。「アクティブ」対時間のピークを追跡しますか？
上記のほとんどをカバー-「アクティブ」RAM=使用量を主な関心事とする必要があります。ただし、オーバーコミットのしきい値を慎重に定義して、特定の比率に達した場合（ これはまともな例です） （少し古いかもしれませんが）通常、私は確かにクラスターRAMの合計の120％以内を維持しますが、どの比率を快適にするかはあなた次第です。
メモリのオーバーコミットに関するいくつかの優れた記事/ディスカッション：
クレイグ・ワトソンからの優れた回答に加えて、以下を追加したいと思います。
VMwareでメモリを過剰にコミットすることは、意図的に行うべきことではありません。一般的に、お客様またはお客様のいずれかがハードウェアをオーバーサブスクライブしていることを示しています。
オーバーコミットが唯一の選択肢である場合、私はstronglyに優先ルールを適用することをお勧めします。重要ではないVM 16GBのvRamを4GBしか必要としない場合、少なくともそのVMを低いリソースプールに置くか、優先度を低くします。重要な本番データベースをハイパーバイザーでスワップアウトしたくない場合。パフォーマンスが低下するだけでなく、バックエンドストレージに対するI/Oキューが消費されます。
非常に高速なストレージ（FusionIO、Violin、ローカルSSDなど）で実行している場合、スワップはそれほど大きな問題ではないかもしれませんが、従来のSANストレージでは、最終的にすべてのVMに影響しますおよび同じアレイ/コントローラに接続されたホスト。