如何描述VMware应用程序对VMwarepipe理员的VMware性能要求？

通常，我们现场的基于debian-stable的应用程序的安装通常在VMware ESXi中运行在虚拟机中。 在一般情况下，我们无法查看或影响虚拟化环境，也无法访问例如VMware vCenter客户端或同等产品。 我在这里关注VMware，因为到目前为止，我们看到的是最常见的。

我们希望：

• 告诉客户的VMwarepipe理员：只要符合性能标准X，Y和Z，就可以在我们的VMware ESX环境中运行我们的应用程序。
• 能够确定X，Y和Z标准是否连续实现（ 即现在也是如此），即使在一个正在运行的系统上（我们不能停止我们的应用程序并运行基准testing，并且初始基准testing也不足够，虚拟环境随时间变化）。
• 有信心，如果符合标准X，Y和Z，我们将有足够的虚拟硬件资源来运行我们的应用程序，performance令人满意。

现在什么是X，Y和Z？

我们一次又一次地看到，当出现性能问题时，问题不在于我们的应用，而在于虚拟化环境。 例如，另一台虚拟机使用大量的CPU，内存或实际存储磁盘的SAN，这些数据会被我们的应用程序以外的其他应用程序所占用。 我们目前无法certificate或反驳这一点。

• x86 / x64虚拟化有多less开销？
• rsync能显示当前的平均速度吗？
• 禁用硬件辅助虚拟化有什么好的理由吗？
• 如何检查每个进程的磁盘I / O利用率
• ServerLimit，MaxClients，MaxRequestsPerChild指令的最佳值

理论上也可能有时我们的应用程序很慢… 😉

如何确定我们的性能问题的根本原因：虚拟环境还是我们的应用程序？

性能问题通常有3个方面：CPU，内存和磁盘I / O。

中央处理器

在例如VMware中，pipe理员可以指定保留和限制，以MHz为单位，但是在一个ESX主机上，例如512MHz与另一个ESX主机上的512MHz完全相同，可能在完全不同的ESX群集中。

如何衡量我们是否真的得到了这个呢？ 当我们的应用程序正在运行时，我们可以看到我们在4个CPU上的CPU利用率为212％。 是因为我们的应用程序做了很多事情，还是因为同一台主机上的另一台虚拟机正在运行一个CPU密集型任务并使用了所有的CPU？

记忆（气球？）

如果我们要求例如16GB内存，这通常是configuration的，但由于膨胀 ，我们实际上只得到4GB，而且我们的应用程序performance不佳。

可以询问VMware工具当前的膨胀情况，但是我们发现它经常存在（或者至less是不准确的）。 我们已经看到了操作系统认为有16GB总RAM的例子，所有进程的驻留内存（RSS）的总和是4GB RAM，但是即使VMware工具告诉我们有0膨胀，也只有2GB RAM。 – （

另外，仅仅添加RSS是无效的，因为可以容易地共享RAM，例如，写入时复制内存，所以512MB + 512MB不一定意味着1GB，但意味着更less的意思。 因此，不能简单地从所有进程中减去RSS，以获得多lessRAM应该是空闲的，从而可靠地检测气球的度量。 人们可以检测到一些气球膨胀的情况，但也有其他情况下气球膨胀是有效的，但是不能用这种方法检测。

磁盘I / O

我想我们可以随着时间的推移读取和写入磁盘的数量，读取和写入的字节数，以及IO等待百分比。 但是，这会给我们一个磁盘I / O的准确画面吗？ 我想如果有一个比特币矿工在使用所有CPU的另一个虚拟机上运行，​​即使底层SAN具有完全相同的性能，我们的IO等待百分比也会增加，这仅仅是因为我们的CPU资源不足，因此IO等待以％衡量 ）上升。

总而言之，我们可以用什么语言来描述VMwarepipe理员，以便携和可测量的方式描述我们需要的性能？