通常，我们现场的基于 debian-stable 的应用程序安装在虚拟机中运行 - 通常在 VMware ESXi 中。一般情况下，我们无法看到或影响他们的虚拟化环境，也无法访问 VMware vCenter 客户端或同等软件。我在这里重点介绍 VMware，因为这是我们目前最常见的。
我们希望：
- 告诉客户的 VMware 管理员：您可以在 VMware ESX 环境中运行我们的应用程序，只要它满足性能标准 X、Y 和 Z。
- 能够确定标准 X、Y 和 Z 是否确实持续得到满足（例如现在），即使在正在运行的系统上也是如此（我们无法停止我们的应用程序并运行基准测试，并且初始基准测试是不够的，因为虚拟环境中的性能会随着时间而变化）。
- 有信心，如果满足标准 X、Y 和 Z，我们将有足够的虚拟硬件资源来运行我们的应用程序并获得令人满意的性能。
那么 X、Y 和 Z 是什么？
我们一次又一次地看到，当出现性能问题时，问题不在于我们的应用程序，而在于虚拟化环境。例如，另一个虚拟机使用了大量 CPU、内存，或者实际存储磁盘的 SAN 被我们的应用程序以外的其他程序大量使用。我们目前无法证明或反驳这一点。
从理论上来说，我们的应用程序有时也可能会很慢...;-)
如何确定性能问题的根本原因：虚拟环境还是我们的应用程序？
性能问题通常有 3 个方面：CPU、内存和磁盘 I/O。
中央处理器
例如，在 VMware 中，管理员可以指定以 MHz 表示的预留和限制，但是一个 ESX 主机上的 512MHz 是否与另一个 ESX 主机上的 512MHz 完全相同，可能在完全不同的 ESX 群集中？
那么如何衡量我们是否真的实现了这一点呢？当我们的应用程序运行时，我们可能可以看到 4 个 CPU 上的 CPU 利用率为 212%。这是因为我们的应用程序正在执行大量操作，还是因为同一主机上的另一个 VM 正在运行 CPU 密集型任务并使用所有 CPU？
记忆（膨胀？）
例如，如果我们要求 16GB RAM，这通常是可以配置的，但由于气球飞行，我们实际上只获得了 4GB，而且令人惊讶的是，我们的应用程序性能很差。
可以向 VMware 工具询问当前的内存膨胀情况，但我们发现它经常撒谎（或至少不准确）。我们见过一些例子，操作系统认为总内存为 16GB，所有进程的常驻内存 (RSS) 总和为 4GB RAM，但只有 2GB RAM 可用，即使 VMware 工具告诉我们内存膨胀为 0 :-(
此外，仅仅将 RSS 相加也是无效的，因为很容易存在共享 RAM，例如写时复制内存，因此 512MB + 512MB 并不一定意味着 1GB，而可能意味着更少。因此，不能简单地从所有进程中减去 RSS 来衡量应该有多少 RAM 可用，从而可靠地检测内存膨胀。可以检测到某些内存膨胀的情况，但也存在内存膨胀确实存在但无法通过此方法检测到的其他情况。
磁盘 I/O
我想我们可以绘制随时间变化的磁盘读写次数、读写字节数以及 IO 等待百分比的图表，但这能让我们准确了解磁盘 I/O 吗？我想象，如果另一台虚拟机中运行的比特币矿工占用了所有 CPU，我们的 IO 等待百分比就会上升，即使底层 SAN 的性能完全相同，这仅仅是因为我们的 CPU 资源下降，因此 IO 等待（以％为单位） 往上。
所以总而言之，我们可以使用什么语言以可移植和可衡量的方式向 VMware 管理员描述我们需要什么样的性能？
答案1
说实话，大多数 VMware 管理员并不擅长这一点：对资源管理了解不足，通常不了解 Linux（这很有帮助）并且缺乏时间。我发现大多数内部管理员都很难保持深入的虚拟化知识。
幸运的是，有一本书你可以读！
大多数 VMware 环境都不太好：集群设计不佳，糟糕的资源规划、不达标准的存储（即 Synology NAS）、HA 配置错误、没有监控或修补。
VMware 作为一个组织让我们失望了：他们尤其不善于传播最新信息和推广最佳实践。尽管流程和设计随着时间的推移发生了变化，但对常见问题的基本搜索会生成 2009 年及更早版本的 VMware 搜索结果。
所有这些事情都会对你不利。
您应该确定解决方案的实际要求。能够准确地说明您的设备需要：2 个 vCPU、8GB RAM 和 500 IOPs 存储性能对我这样的人来说意义重大。
另一种方法是观察健康或理想的环境并从中推断出指标。
您描述了某些部署中存在的问题。问题和瓶颈是什么？
合适大小的虚拟机的示例：
一个拥有 300 个用户的组织的 Exchange 服务器。
- 我们有 6 周的工作量/压力与时间的热图。
- 6 个 vCPU 使我们处于压力区之上，并为峰值提供了缓冲空间。
- 32GB RAM 让我们高于压力值，但也不是超出实际需要的不合理数量。
- 我可以回收几 GB 的 RAM 和一个 vCPU，但总的来说，这是一个高效的虚拟机。
- 在理想条件下对您的应用程序进行这种类型的监控是明智的。
VM 资源监控的示例。
不错： - VM 大小合适。 - 集群中的 CPU 过度使用，但我们没有遇到争用。
不好的地方：
- VM 永远不会获得其配置的所有 RAM。
- VM 正在交换 RAM。
- CPU 配置过度。
