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
>从虚拟sql Server环境中的备份还原测试数据库
>在本地连接数据库
>运行脚本 – 此步骤需要9秒
我的桌面上的相同过程在不到1秒的时间内运行第3步.
测试案例#2
>从物理sql Server环境中的备份还原测试数据库
>在本地连接数据库
>运行脚本 – 此步骤不到1秒
但是在事务中运行脚本的速度很快
测试案例#3
>从虚拟sql Server环境中的备份还原测试数据库
>在本地连接数据库
>在脚本的开头添加“BEGIN TRAN”
>在脚本末尾添加“COMMIT TRAN”
>运行脚本 – 此步骤不到1秒
我觉得有趣的是,即使我在事务中执行一次并将其回滚,它仍然运行缓慢
测试案例#4
>从虚拟sql Server环境中的备份还原测试数据库
>在本地连接数据库
>在脚本的开头添加“BEGIN TRAN”
>在脚本末尾添加“ROLLBACK TRAN”
>运行脚本 – 此步骤不到1秒
>仅执行不包含事务的脚本部分 – 此步骤需要9秒.
我已经在Windows 2003 32位和sql 2005 32位及以及具有Windows 2008 64位和sql 2008 64位的虚拟系统的虚拟系统上运行测试.我已经在使用Windows 2003和sql 2005的物理系统上以及使用Windows 7 64位和sql 2008 R2 64位的物理系统上运行测试.我尝试过的所有虚拟系统都表现出这种速度,并且托管在新的ESXi环境中.所有物理系统都没有表现出这种缓慢.
任何人都可以帮我理解这里发生了什么？我担心类似的性能问题正在影响其他领域,我们应该在主机或访客环境中重新配置一些东西.到目前为止我们唯一可以想到的是关闭主机BIOS中的超线程以匹配另一个虚拟环境的配置和我们无法看到缓慢行为的主机(我没有观察到测试另一个虚拟环境和主机,它不是很慢).这会产生如此大的性能差异吗？
编辑：在对我的问题和第一个答案进行一些审核之后,我同意我设法演示的内容可能是我们的物理和虚拟环境之间I / O延迟性能的差异.我还意识到我应该提供一些其他细节：这些图像使用精简配置,并且在它们下面有两个或三个快照.这会如此显着地影响该统计数据吗？现在的问题是,这个统计数据在虚拟环境和物理环境之间如此截然不同是否正常？我是否应该能够在环境或sql配置中对其进行优化,还是由软件本身来为具有极端I / O延迟的虚拟系统进行更优化的编写？
vSphere客户端报告虚拟磁盘上的写入延迟为11到40毫秒,平均为21毫秒.这是一个有用的统计数据吗？那是极端吗？
编辑：
看来我们的硬件(DL380 G6)存在性能问题,如http://laez.nl/vmware-bad-performance-on-hp-proliant-dl380-g6-with-esxi-3-5-u4/所述,我们只需要进行一些重新配置即可提高性能.我会接受这样的答案,这些答案使我们朝着正确的方向发现磁盘I / O延迟是个问题.
解决方法
>在您的真实服务器上,您可以在不到一秒的时间内完成1700个表更新1700次提交,
>在您的虚拟服务器上,您可以在9秒内完成1700个表更新1700次提交,您可以在不到一秒的时间内完成1700个表更新1次提交.
因此在我看来,您的问题可以重新定义为“在真实的服务器上,我可以在不到一秒的时间内完成1700次提交,但性能在我的虚拟服务器上下降了十倍”.
1700个表更新和1700个提交有什么区别？表更新完全缓存,完全不依赖于磁盘I / O.提交时,这是完全不同的.根据事务数据库的本质,数据库引擎必须确保提交已经实际保存到磁盘(保存到日志文件),然后才开始提交下一个事务.因此,对于这1700次提交中的每一次,它必须等待整个I / O往返.总而言之,在您的场景中,I / O的延迟起着非常重要的作用,并且应该进行分析(不要将延迟与I / O速率或吞吐量以字节为单位误认为;这三者都是完全不同的动物;它们是总是单独调整).
使用IOMeter测试存储是一个很好的计划.它在启动时挂起,因为它试图用它的测试文件填满整个磁盘.只要等到文件增长到相当大的数量并重新启动IOMeter,它就能与“不完整”的测试文件一起正常工作.
