通常，基于Debian稳定的现场应用程序的安装通常在虚拟机中运行-通常在VMware ESXi中。在一般情况下，我们无法了解或影响其虚拟化环境，也无法访问例如VMware vCenter客户端或类似产品。我在这里重点介绍VMware，因为到目前为止，这是我们看到的最常见的情况。
我们希望：
- 告诉客户的VMware管理员：只要满足性能标准X，Y和Z，您就可以在您的VMware ESX环境中运行我们的应用程序。
- 即使在正在运行的系统上，也能够确定条件X，Y和Z是否实际上连续满足（例如，现在也是如此）（我们无法停止应用程序并运行基准测试，而初始基准测试也无法满足要求，因为虚拟环境随时间而变化）。
- 确信如果满足标准X，Y和Z，我们将有足够的虚拟硬件资源来以令人满意的性能运行我们的应用程序。
现在X，Y和Z是什么？
我们一次又一次地看到，当出现性能问题时，问题不在于我们的应用程序，而在于虚拟化环境。例如，另一个虚拟机使用大量的CPU，内存或实际存储磁盘的SAN，除了我们的应用程序外，它们还会大量使用。我们目前无法证明或反驳。
从理论上讲，有时我们的应用程序速度很慢... ;-)
如何确定导致性能问题的根本原因：虚拟环境或我们的应用程序？
CPU，内存和DISK I / O通常存在3个性能问题区域。
中央处理器
在例如VMware中，管理员可以指定保留和限制（以MHz表示），但是例如在一台ESX主机上的512MHz是否与另一台ESX主机上的512MHz完全相同，可能是在完全不同的ESX群集中吗？
以及如何衡量我们是否真的得到了呢？当我们的应用程序运行时，我们也许可以看到我们在4个CPU上的CPU利用率为212％。是因为我们的应用程序执行大量操作，还是因为同一主机上的另一个VM正在运行CPU密集型任务并使用了所有CPU？
记忆（气球？）
如果我们要求例如通常配置的16GB RAM，但是由于气球增加，我们实际上只能得到4GB，令人惊讶的是，我们的应用程序性能很差。
有人可以向VMware工具询问当前的膨胀，但是我们发现它经常存在（或者至少是不准确的）。我们已经看到了一些示例，其中操作系统认为总RAM为16GB，所有进程的驻留内存（RSS）的总和为4GB RAM，但是只有2GB可用RAM，即使VMware工具告诉我们0迅速增加： -（
同样，仅将RSS加在一起也是无效的，因为可以很容易地共享RAM，例如写时复制内存，所以512MB + 512MB不一定意味着1GB，但是可能意味着更少。因此，不能简单地从所有进程中减去RSS来衡量应该释放多少RAM，从而可靠地检测出膨胀。一个人可以检测到气球膨胀的某些情况，但是在其他情况下，气球膨胀是有效的，但这种方法无法检测到。
磁盘I / O
我想我们可以随时间绘制磁盘读取和写入的数量，读取和写入的字节数量以及IO等待百分比的图形。但这是否可以为我们提供磁盘I / O的准确情况？我想如果在使用所有CPU的另一台VM上运行一个比特币挖矿机，即使底层SAN提供了完全相同的性能，我们的IO等待％也会增加，这仅仅是因为我们的CPU资源下降，因此IO等待（以％表示）。
因此，总而言之，我们可以使用哪种语言来描述例如VMware管理员，以可移植且可衡量的方式来描述我们所需的性能？
"It runs fine with x, y, and z"的不够精确。您需要能够准确地告诉客户您的应用程序需要什么。如果他们为您提供了这些资源，并且应用程序运行不佳，那么问题就不是了"What do we need from a resource perspective?"，而是"Why is it performing poorly even though the proper resources have been allocated?"
