我们最近设置了一台新的机器，它有8个双核CPU，20GB RAM和3个1TB驱动器，这些驱动器安装在某种RAID中，我们实际上可以使用2个1TB驱动器（我不是硬件人在这里）。 它被设置为ESXi主机，我们在其中设置了许多testing环境。 目前的testing运行在Windows 2003 64位和SQL Server 2005 Standard 64位SP3上。 从所有的报告来看，这个系统应该托pipe比我们以前的设置更好的环境，但是某些任务performance更差。 我发现了一个特定的SQL脚本，在某些条件下可靠运行非常缓慢，这是我无法理解的。 SQL脚本是一系列简单的1700+ UPDATE语句，它们是这样开始的：
UPDATE SrfItem SET fkSrfItem = 5 WHERE id = 4 UPDATE SrfItem SET fkSrfItem = 8 WHERE id = 7 UPDATE SrfItem SET fkSrfItem = 10 WHERE id = 9 我发现如果我在其中一个虚拟环境中按照以下过程运行脚本需要9-12秒：
我的桌面上的相同过程在不到1秒的时间内运行第3步。
但是，在事务中运行脚本会很快
我觉得有趣的是，即使在事务中执行一次并回滚之后，它仍然运行缓慢
我已经使用Windows 2003 32位和SQL 2005 32位和虚拟系统以及Windows 2008 64位和SQL 2008 64位的虚拟系统在虚拟系统上运行testing。 我已经在Windows 2003和SQL 2005的物理系统上以及Windows 7 64位和SQL 2008 R2 64位的物理系统上运行testing。 我尝试过的所有虚拟系统都performance出这种缓慢性，并且托pipe在新的ESXi环境中。 所有的物理系统都不显示这种缓慢。
任何人都可以帮助我理解这里发生了什么？ 我担心类似的性能问题会影响其他领域，我们应该在主机或客户环境中重新configuration一些东西。 我们现在唯一能想到的就是closures主机BIOS中的超线程，以匹配另一个虚拟环境和主机的configuration，我们无法看到缓慢的行为（我没有观察到testing另一个虚拟环境和主机不慢）。 那能创造如此大的性能差异吗？
编辑：经过对我的问题和第一个答案的一些回顾后，我同意，我设法展示的可能是我们的物理和虚拟环境之间的I / O延迟性能的差异。 我也意识到，我应该提供一些其他的细节：这些图像使用精简configuration，并有两个或三个快照下。 这可能会如此显着地影响统计数据吗？ 现在的问题是，这个统计数据在虚拟环境和物理环境之间是如此巨大的不同？ 我应该能够在环境中还是在SQLconfiguration中对其进行优化，还是对于具有极端I / O延迟的虚拟系统而言，能够更好地编写软件本身？
vSphere客户端报告虚拟磁盘上的写入延迟时间为11到40毫秒，平均值为21毫秒。 这是一个有用的统计数据吗？ 这是极端的吗？
编辑：看来我们的硬件（DL380 G6）有性能问题，如http://laez.nl/vmware-bad-performance-on-hp-proliant-dl380-g6-with-esxi-3-5-u4 /我们只需要做一些重新configuration来提升性能。 我会接受导致我们正确看待磁盘I / O延迟问题的答案。
总结一下：
所以在我看来，你的问题可以被重新定义为“在真正的服务器上，我可以在不到一秒的时间内完成1700次提交，但是性能在我的虚拟服务器上下降了10倍”。
1700表更新和1700提交有什么区别？ 表更新完全caching，完全不依赖于磁盘I / O。 承诺这是完全不同的。 根据事务数据库的本质，数据库引擎必须确保提交在甚至开始提交下一个事务之前已经实际保存到磁盘 （保存到日志文件）。 所以对于1700个提交中的每一个，都必须等待整个I / O往返。 总结一下，在你的场景中，I / O的延迟起着非常重要的作用，应该进行分析（不要把延迟与I / O速率或者吞吐量错误地以字节为单位;这三个都是完全不同的动物;它们是总是单独调整）。
用IOMetertesting你的存储是一个很好的计划。 它在启动时挂起，因为它试图用自己的testing文件填充整个磁盘。 只要等到文件增长到相当大的数量，重新启动IOMeter，就可以正常使用“不完整”的testing文件。
你的澄清揭示了这个问题。
3驱动器SATA RAID 5包不是用于写入性能的最佳磁盘configuration。 每个IO写入[高达] 4个磁盘IO（读取当前块，读取当前奇偶校验，写入新块，写入新奇偶校验）。 实际上，如果您的基本驱动器是7200转/分钟，这将把您的三个7200转/分钟的磁盘变成一个更像一个5400rpm驱动器的磁盘。
其次，你说在SQL虚拟机上有许多活动的快照。 VMware ESXi快照会产生不小的开销，具体取决于您正在做什么，当您拥有活动快照时，会有50-100％的IO开销。 这会影响读取和写入。
第三，你说你正在使用自动精简configuration – 这对IO性能有影响，但并不像其他两个那么重要。
最后，您不会说ESXi主机上是否有其他虚拟机正在运行 – 如果存在这些虚拟机，将会明显影响整体性能，尤其是对于RAID5 x 1TB SATA磁盘设置。
我不认为你的testing真的是强大的，以确定虚拟系统有问题。 一秒钟的testing没有给予足够的时间来强调系统显示任何真正的瓶颈。
在虚拟世界中，在SQL Server中有许多移动部分。 我认为磁盘IO是这里的主要玩家，也是RAM。 ESX可以根据需要向guest虚拟机提供RAM，并且ESX有时需要几秒钟的时间才能做出反应，从而产生短暂停顿。 如果一个服务器在一定的负载下，那么ESX会稳定RAM，但是如果testing很短并且爆发，那么可能需要一段时间才能升级。
在你开始用洗澡水把宝宝扔出去之前，运行更长时间的testing并用ESX进行监视，并且监视RAM使用情况，磁盘IO延迟，CPU队列长度等。一个好的testing需要30到60秒才能在物理机器上运行，我希望虚拟机在150％以内。