VMware 内存管理似乎是一项棘手的平衡工作。集群 RAM、资源池、VMware 的管理技术（TPS、膨胀、主机交换）、客户机内 RAM 利用率、交换、预留、共享和限制等变量非常多。
我处于客户端使用专用 vSphere 集群资源的情况。然而，他们将虚拟机配置得就像在物理硬件上一样。反过来，这意味着标准 VM 构建可能具有 4 个 vCPU 和 16GB 或更多 RAM。我来自从小处着手（1 个 vCPU，最小 RAM）的学校，检查实际使用情况并根据需要进行调整。不幸的是，许多供应商要求和不熟悉虚拟化的人要求的资源比必要的要多……我对量化这一决定的影响很感兴趣。
来自“问题”集群的一些示例。
资源池摘要 - 看起来几乎是 4:1 的超额使用。请注意膨胀的 RAM 数量很高。
资源分配 - 最坏情况分配列显示，在受限条件下，这些虚拟机只能访问其配置的 RAM 的不到 50％。
上面列表中顶级虚拟机的实时内存利用率图表。分配了 4 个 vCPU 和 64GB RAM。平均使用量低于 9GB。
同一虚拟机的摘要
在 vSphere 环境中过度承诺和过度配置资源（特别是 RAM）有哪些缺点？
假设虚拟机可以在较少的 RAM 中运行，那么是否可以说为虚拟机配置比其本身更多的 RAM 会产生开销？实际上需要？
反驳的论点是什么：“如果虚拟机分配了 16GB 的 RAM，但只使用了 4GB，会有什么问题呢？“？例如，是否需要教育客户虚拟机与物理硬件不一样吗？
应使用哪些特定指标来衡量 RAM 使用情况。跟踪“活动”峰值与时间的关系？观察“已消耗”？
更新：我用了vCenter Operations Manager来分析此环境并获取上面列出的集群统计信息的一些详细信息。虽然情况肯定是过度承诺的，但虚拟机实际上所以过度配置了不必要的 RAM，以至于实际（微小）内存占用在集群/主机级别没有显示内存争用......
我的看法是，虚拟机应该有合适的大小，并留出一点缓冲区用于操作系统级缓存。由于无知或供应商“要求”而过度使用会导致此处出现的情况。内存膨胀似乎在任何情况下都是不好的，因为它会影响性能，因此适当的大小调整可以帮助防止这种情况。
更新 2： 其中一些虚拟机开始崩溃：
kernel:BUG: soft lockup - CPU#1 stuck for 71s!
VMware 将其描述为内存过度使用症状. 所以我想这回答了这个问题。
vCops“超大虚拟机”报告……
vCops“可回收废物”图表……
答案1
vSphere 的内存管理相当不错，尽管其使用的术语经常引起很多混淆。
一般情况下，应避免内存过度使用，因为它会产生此类问题。但是，有时无法避免，所以预先警告就是预先准备！
在 vSphere 环境中过度承诺和过度配置资源（特别是 RAM）有哪些缺点？
过度承诺资源的主要缺点是，如果您有争用，您的主机将被迫在后台膨胀、交换或智能地调度/重复数据删除，以便为每个虚拟机提供所需的内存。
对于膨胀，vSphere 将在所选 VM 中膨胀 RAM“膨胀”，然后将膨胀的 RAM 提供给需要它的客户机。这实际上并不是“坏事”——VM 正在窃取彼此的 RAM，因此不会进行磁盘交换——但如果这些依赖于分析 VM 的 RAM 使用情况，则可能导致警报错误和指标偏差，因为 RAM 不会被标记为“膨胀”，只是被操作系统“使用中”。
vSphere 可以使用的另一个功能是透明页面共享 (TPS) - 本质上是 RAM 重复数据删除。vSphere 将定期扫描所有分配的 RAM，查找重复的页面。找到后，它将删除重复数据并释放重复的页面。
看一眼vSphere 的内存管理白皮书 (PDF)- 特别是“ESXi 中的内存回收”（第 8 页）- 如果您需要更深入的解释。
假设虚拟机可以在更少的 RAM 下运行，那么是否可以说为虚拟机配置比其所需更多的 RAM 会产生开销？
没有可见的开销 - 你可以在具有 16 GB 的主机上分配 100GB 的 RAM（但这并不意味着你应该，原因如上所述）。
所有虚拟机使用的总内存是图表中显示的“活动”曲线。当然，在计算您想要超额使用多少内存时，您不应该只依赖这个数字，但如果您有历史指标，您可以根据实际使用情况进行分析和计算。
本文讨论了“活动”RAM 和“已消耗”RAM 之间的区别VMWare 社区主题。
反驳的论点是什么：“如果虚拟机分配了 16GB 的 RAM，但只使用了 4GB，会有什么问题？”? 例如，是否需要对顾客进行教育？
简短的回答是是的- 顾客应该总是接受最佳实践的教育，无论他们使用什么工具。
应该教育客户根据自己的需求调整虚拟机的大小使用，而不是他们想很多时候，人们会过度指定他们的虚拟机，只是因为他们可能需要 16 GB 的 RAM，即使他们过去每天都只能用 2 GB 内存。作为 vSphere 管理员，您拥有知识、指标和权力来挑战他们，并询问他们是否真的需要他们分配的 RAM。
也就是说，如果将 vSphere 的内存管理与精心控制的过度提交限制相结合，那么在实践中很少会遇到问题，长时间耗尽 RAM 的可能性相对较小。
此外，自动化 vMotion（称为分布式资源调度由 VMware 开发）本质上是虚拟机的负载均衡器 - 如果单个虚拟机占用过多的资源，DRS 应该会迁移虚拟机以充分利用集群的资源。
应该使用什么具体指标来衡量 RAM 使用情况。跟踪“活动”峰值随时间的变化？
上面主要介绍了 - 你主要关注的应该是“活动”RAM 使用情况，但你应该仔细定义你的过度使用阈值，以便如果达到一定比例（这是一个很好的例子，尽管它可能有点过时）。通常，我肯定会将总集群 RAM 保持在 120% 以内，但您可以自行决定自己喜欢的比例。
关于内存过量提交的一些好文章/讨论：
答案2
除了 Craig Watson 的出色回答之外，我还想补充以下内容：
在 VMware 中过度使用内存并不是你故意为之。这通常表明你或你的客户对硬件的使用过度。
如果过度承诺是唯一的选择，那么我强烈建议您执行优先级规则。如果有人执意要为非关键 VM 提供 16GB 的 vRam，而它只需要 4GB - 至少将该 VM 放在低资源池中或为其提供低优先级。您真的不希望关键生产数据库被虚拟机管理程序交换出去。这不仅会降低性能，还会占用后端存储的 I/O 队列。
如果您使用的是超快存储（FusionIO、Violin、本地 SSD 等），那么交换可能不是什么大问题，但使用传统的 SAN 存储，您最终会影响连接到同一阵列/控制器的每个 VM 和主机。