在讨论CPU队列如何工作以及它最终如何影响您的应用程序和环境性能时，不乏困惑。虚拟化通过实现物理硬件资源的共享给业界带来了一些美妙的东西，但它也为it运营和应用程序开发人员每天都在努力解决的隐藏问题打开了大门。让我们快速回顾什么是CPU排队，以及处理器等待时间如何在堆栈的更高层产生灾难性影响。虚拟CPU体系结构概述每个物理CPU将被划分为虚拟核心，并由hypervisor共享，后者为虚拟工作负载提供资源。一个4处理器的服务器，每个处理器有24个内核，总共96个内核可用于虚拟工作负载。虚拟机可以分配多个CPU，这些CPU映射到主机服务器的物理核心和CPU体系结构。请求CPU资源的vm根据虚拟到物理的映射进行排队。具有多CPU应用程序请求的4-vCPU虚拟机不仅需要虚拟访问，还需要物理访问4个并发CPU。如果任何CPU正在处理现有请求，则4-vCPU虚拟机正在等待完成其请求。VMware文档表明：即使虚拟机中的当前工作负载实际上只需要虚拟CPU的一部分，该工作负载也必须等到所有虚拟核心（即使是当前未使用的虚拟核心）都可以在物理处理器上运行为止。这种行为也被称为"co-stop"有许多因素会导致协同调度等待时间。应用程序需求的波动将导致底层hypervisor和主机不断尝试调度可用的CPU资源。这些等待时间虽然看起来很小，但却产生了非常实际的影响。CPU排队的影响是什么？这在您的虚拟化环境中是如何实现的？这是典型的CPU和内存在虚拟与物理比率中的超额订阅。这是为虚拟化环境设计的。即使是保守的超额订阅的hypervisor主机也会看到很长的等待时间，这在肉眼看来并不是问题。您的应用程序（以及您的客户和员工）肯定会为CPU排队问题付出代价。问题1：峰值=性能下降到达峰值的CPU等待时间会导致队列增加。这些在本机工具中很难看到，但真正的效果是在应用程序层，事务缓慢，应用程序响应延迟。在任何虚拟机监控程序中，所有类型的工作负载都会出现性能下降和风险。您可以从活动VDI环境中的一个视图中看到CPU利用率的峰值正在发生，这与用户体验相关问题.CPU在这些高峰时间，队列深度会增加，从而导致应用程序延迟。这对于对延迟敏感的工作负载至关重要，并且会对任何类型的工作负载产生负面的性能影响。不仅直接应用程序受到影响，而且任何导致高CPU使用率和排队的VM现在都将影响同一物理主机上的每个VM、每个容器和每个应用程序。现在，您的应用程序服务器可能会使呼叫中心应用程序脱机或停止进入数据库应用程序的事务流。问题2：虚拟CPU分配过度/不足最常见的支持多CPU的工作负载之一是虚拟化SQL服务器。大多数SQL发行版甚至推荐了至少有4个cpu，但通常更高的最佳实践。假设我们有一个8vcpu虚拟机，有24gb的RAM，SQL应用程序将需要排队等待所有8个cpu的可用性，这可能会导致一些等待时间。等待时间会导致查询速度变慢，SQL性能变差，任何依赖于SQL server的应用程序都将因此受到影响。VMware甚至在其长达82页的指南中清楚地记录了这一风险，该指南介绍了构建SQL for vSphere的推荐做法：即使来宾操作系统不使用某些vCPU，使用这些vCPU配置虚拟机仍然会对ESXi施加一些小的资源需求，这些资源需求转化为主机上的实际CPU消耗。（一）您可以看到多vCPU系统的利用率峰值和排队的实际影响。即使使用本机工具的功能来管理它，您现在也不可避免地要体验它。解决最高性能挑战CPU利用率峰值和高CPU队列深度不能通过简单地依赖本机调度器来解决。无论是在虚拟化平台还是在集装箱平台上，这一点都被证明是正确的。现在，您可以看到全面的影响，这导致了以经济的方式自动移动和调整资源的大小，从而在整个被自动化的集群中，从应用程序到性能都得到了提高。下一步是将25多个完全不同的群集虚拟地合并到5个虚拟"超级群集"中，从而在短短7天内将主机总数从80多个减少到60个以下！所有这些都是在提高整个应用程序环境的性能的同时，最终的主机重新分配重新启动了一个新的数据中心项目，该项目由于缺乏获取新服务器的能力而冻结。解决CPU计数难题最近出现了一个真实的例子，它强调了Turbonic如何解决任何应用程序（包括SQL Server）的性能问题。一个DBA收到了SQL性能缓慢的通知，他们认为这与CPU问题有关。IT操作团队调查主机，在接到DBA的呼叫时没有发现任何一致的模式或活动问题。没有人知道如何用本机工具和数据解决这个问题。Turbonomic表示调整SQL server大小的操作，将其大小从16 vCPU减小到8-vCPU，以提高性能。虽然这看起来有悖常理，但TurboEconomic平台发现，由于16-CPU指令的CPU队列等待时间更短，SQL server将始终具有更好的应用层性能。通过迁移到8-vCPU，SQL应用程序增加了对可用CPU的访问，这些CPU的队列要少得多深度。两者都有DBA和操作团队现在有了精确的决策、行动和分析来支持他们的选择。它们还能够自动化扩展策略，以便服务器可以根据需要动态扩展，以防将来发生争用。这是一个应用程序的视图，以及它是如何开始降低峰值的，并且未来的操作已经可以用来进一步降低波动性和增加整体应用程序表演。现在我们可以看到，当您启用Turbonic来放置和扩展虚拟机时会发生什么，这将显著降低峰值利用率、CPU就绪性（VMware），从而提高了整个应用程序的性能。证明了按性能调整大小实际上是正确的解决方案，并且使用经济的应用程序资源管理确保可以动态地执行此操作而无风险。性能远远超过高峰和排队这两种技术通过降低CPU性能的峰值和调整大小而实现，已经在数千个环境中得到了验证，但这只是我们要强调的两个具体问题。可能存在许多其他性能风险，这些风险涉及内存、存储、网络等等。我们想在这里强调CPU队列对应用程序性能的具体影响。在这里的博客上寻找更多有价值的性能技巧和技巧，以及TurboEnomicApplication Resource Management Platform如何帮助您！参考文献：（1）https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/solutions/sql-server-on-vmware-best-practices-guide.pdf