我们正在使用一个大约有 300 个并发用户的应用程序。现在一切都虚拟化了：1 个 VM 作为负载平衡器，2 个 VM 作为 Web 服务器（此 ESXi 主机上还有另外 +25 个其他 VM），1 个服务器（裸机）作为 SQL Server。我们在性能方面遇到了一些问题，因此决定购买物理硬件来提升性能。
我不确定我们如何才能获得更好的性能？：
我们购买 1 机架服务器硬件并运行 ESXi，其中仅包含上述所有 3 个虚拟机，
我们为网络服务器购买 1-1 机架服务器硬件，并安装带有应用程序的 Windows 服务器。（并将负载平衡器保留为以前的样子 - VM）
- 我们购买了 3 台机架服务器用于负载均衡器和 2 台 Web 服务器。
用户通过 Web 界面/桌面应用程序连接到服务器。
谢谢你的帮助，drewo
答案1
在决定前进的道路之前，你应该找到一些信息的答案：
受影响虚拟机的 CPU 使用率
- 从客户操作系统的角度来看，CPU 使用率是否经常超过 80%，并且/或者使用率处于稳定状态而不是峰值？您的虚拟机可能 CPU 不足。添加更多 vCPU（但要考虑可能的许可问题）。
- 您的服务器中某些 vCPU 的负载是否比其他 vCPU 低很多？您的应用程序可能存在扩展问题，简单地将更多 vCPU 放入单个 VM（或物理机）并不能解决问题。
- 这些时间是否
CPU ready表明主机已超额使用？您有时会看到一个经验法则，即您希望平均就绪时间少于 5%，但我的经验是，对于您实际工作的系统而言，即使是这个时间也太多了。请注意，如果您使用 vCenter，则指示的就绪时间是自上次图表更新以来的总毫秒数。在“实时”视图中，图表每 20 秒（=20000 毫秒）更新一次，因此可以使用公式计算虚拟机每个 CPU 的平均百分比(indicated_ready_time * 100 / 20000) / number_of_vcpu。
RAM 使用情况
（应始终从客户操作系统内部进行检查）
- 一般在80%以上？加内存。
- 有内存泄漏的迹象？修复应用程序或准备更频繁地重新启动/重启。
- 有频繁交换的迹象？请检查配置问题。添加内存。
- 您是否有关键应用程序/进程“莫名其妙地”使用了少于 4 GB 的内存？它们可能需要重建或重新配置才能使用 64 位寻址。
还要检查磁盘和网络性能是否存在延迟问题。
根据应用程序的扩展方式，可能会考虑添加更多的 Web 服务器，而不是在现有服务器上添加计算能力或内存。
一旦您了解了您的瓶颈在哪里以及如何最好地利用您的硬件，您就可以开始制定购买的商业案例。
虚拟机的主要优势在于它们更易于管理、更易于备份，并且在系统发生故障时更易于迁移。它们可以更好地利用您的硬件，前提是它们实际上不需要您投入的所有资源，并且如果您使用半虚拟化网络接口，则同一主机上的机器之间的通信速度与 CPU 可以管理的速度一样快，而不受物理网络接口速度的限制。
当然，直接在物理机上运行的系统不会因为资源共享而产生开销，但只有在您可以使用可用功能时这才会带来好处。
答案2
如果不调查性能问题的原因和对应用程序的了解，您就无法判断什么是最简单/最佳的补救措施。
如果您的问题确实是缺乏硬件资源，那么监控应该可以清楚地表明您现在在哪里达到了极限以及需要购买什么（CPU 内核或 CPU 速度、更多 RAM 内存、更快的磁盘）以及将其分配到哪里。
根据我的经验，超过一半的性能问题都可以通过适当的调整来解决，而不是投入更多的硬件资源。大多数开发人员和太多供应商没有能力或资源使用与生产中相同的数据量和类似的负载来测试他们的应用程序和数据库后端，他们做出的假设和设计选择在实践中不会很好地扩展。
仔细的监控将让您了解您的瓶颈是什么以及在应用程序、数据库或硬件级别可能需要解决的问题。
请注意，性能分析和调整既是一门科学，也是一门暗黑艺术。
非常常见的应用问题可以轻松解决，并且通常能带来显著的好处，包括
- 数据库中缺少索引
- 连接池和查询缓存
- 调整内存限制、连接数、套接字和应用程序的并发线程
应用程序设计中更难解决的缺陷是应用程序前端的数据处理逻辑太多，而数据库查询过于简单、不受约束且返回太多数据（例如SELECT * from GrowingDataSet）——在您的监控中，此类症状可能多种多样，例如数据库服务器上的高磁盘 IO 负载——应用程序服务器上的高内存消耗——网络链接饱和——每个都可以用来支持不同的硬件购买决策（升级数据库服务器中的 SSD——增加应用程序服务器中的 RAM——升级网络），当应用程序开始在查询中应用更好的逻辑和分页时，可能不需要这些。