我们目前正在我的环境中进行讨论。 假设是这样的
“为Linux中的物理基础架构内存pipe理（如top，free，vmstat，/ proc / meminfo）devise的工具不适用于ESXi虚拟机pipe理程序中的虚拟机，因为它们依赖于操作系统直接监视物理RAM的能力在一个裸机系统。 在虚拟基础架构中，客户操作系统不能查看物理硬件，而只能查看（ESXi）pipe理程序模拟的虚拟硬件。 由于操作系统无法直接访问大部分主机服务器的物理硬件，传统的性能监控工具将无法在虚拟基础架构中正常运行。
在VM guest（SLES 11）中，我们看到RAM利用率在93％左右。 但是在vSphere / vCops中显示的分配RAM的8388608（8GB）KB为5072309 kb的Active Write。 大约有60.46％的利用率。
问题是，上述假设是否正确，如果是的话：
如果guest虚拟机内部的guest虚拟机在虚拟机中不准确，并且达到100％的内存利用率，那么VM guest虚拟机将进行交换，如果这样，我推测位于SAN上的vswp会导致VM Guest虚拟机出现减速。
这取决于。 你应该依靠虚拟机内的工具，比如top，vmstat等等，它们是准确的，假设你的物理资源不是太过分，你已经安装了VMware工具。 在vSphere级别，您仍然有内存膨胀，TPS，压缩和交换作为后备。 内存pipe理确实不是那么糟糕。
还要了解vSphere / vCenter指标和vCops指标是完全不同的（vCops已被VMware收购，并使用自己的algorithm来衡量资源利用率）。
衡量虚拟机级别的利用率。 使用vCops或vCenter来规划集群级别的资源。
请勿过度使用RAM，因为这会影响度量标准，并对性能产生明显的影响 。
他们的应用types也很重要。 如果是基于Java的繁重，则需要一些其他方法（ 部分或全部保留 ）来帮助它们在vSphere环境中有效地运行。