SQL Server 2014 中的 CPU 时间比 SQL Server 2008 中的慢

6 performance sql-server-2008 sql-server sql-server-2014

我们正在将虚拟化数据库服务器从旧的 SQL Server 2008 R2 Standard (vmware) 升级到新的闪亮的 SQL Server 2014 Standard 服务器 (hyper-v)。我们正在做一些性能测试,令我们惊讶的是,新服务器系统的 CPU 时间似乎比旧的、噼啪作响的旧系统更糟糕。这些是系统:

旧服务器:

  • 在虚拟机 VMWare ESX 5.1 中运行
  • Windows Server 2008 R2 32 位
  • SQL Server 2008 R2
  • 四核至强 ES-2620 2Ghz
  • 5600MB 内存

新服务器:

  • 在虚拟机 Hyper-V UEFI 版本 v1.0 中运行
  • 视窗服务器 2012 R2
  • SQL Server 2014
  • 四核至强 ES-2640 2.6Ghz
  • 32766 MB 内存

我们所做的一些历史:

  • 两个不同的基准测试表明,在新服务器中,CPU 速度提高了约 80%,内存访问速度提高了约 100%,IO 磁盘访问速度提高了约 1000%。
  • 测试查询使用具有非聚集索引的多个连接。
  • 在两台服务器中,测试数据库完全相同。
  • 在两台服务器中,能源电源选项都设置为高性能,并且还使用 CPU-Z 检查处理器始终处于最大速度。
  • 在两台服务器中都启用了“锁定页面”。
  • 在两台服务器中,执行测试查询时,统计信息都得到了正确更新,查询计划也相同。
  • 为了确保计划始终相同,我们在兼容模式 100 (SQL Server 2008) 的 SQL Server 2014 中执行查询,但如果没有这种兼容模式,结果是相同的。
  • 两台服务器中的最大内存选项都设置为默认值 (2147483647),我们还检查了并行度(最大程度设置为相同,成本也相同)
  • 新服务器是专用的(没有其他东西在那里运行)

在所有这些检查之后,对于仍在旧服务器中的缓存查询(仅由 CPU 时间引起),我们获得了更好的时间结果。

测试查询:

SELECT ROW_NUMBER() OVER(ORDER BY c.field1, c.field2) AS RowNumber, a.t1_t3ID, c.field1, c.field2, a.t1_t2ID, b.field1, a.BeginDate, a.EndDate, c.field3 FROM table1 a INNER JOIN table3 c ON a.t1_t3_ID = c.t3_PKID INNER JOIN table2 b ON a.t1_t2ID = b.t2_PKID WHERE '20140101' BETWEEN a.BeginDate AND a.EndDate

查询执行计划(两台服务器相同,百分比相同):

在这里查询执行计划

两台服务器上 CPU 时间的结果:

旧服务器:

  • CPU 时间 = 93 毫秒,经过时间 = 65 毫秒。
  • CPU 时间 = 94 毫秒,经过时间 = 99 毫秒。
  • CPU 时间 = 94 毫秒,经过时间 = 70 毫秒。
  • CPU 时间 = 93 毫秒,经过时间 = 63 毫秒。
  • CPU 时间 = 93 毫秒,经过时间 = 67 毫秒。

新服务器:

  • CPU 时间 = 125 毫秒,已用时间 = 309 毫秒。
  • CPU 时间 = 141 毫秒,已用时间 = 304 毫秒。
  • CPU 时间 = 139 毫秒,已用时间 = 288 毫秒。
  • CPU 时间 = 156 毫秒,已用时间 = 277 毫秒。
  • CPU 时间 = 142 毫秒,已用时间 = 323 毫秒。

注意:我们还检查了 CONVERT_IMPLICIT 在这种情况下不会影响性能。

我们观察到的是,如果我们强制只使用一个处理器核心,旧服务器的 CPU 时间大致保持不变。如果我们在旧服务器上做同样的事情,执行计划就会切换到表扫描,CPU 时间会增加到 800 毫秒。

有人知道仍然可以检查/测试什么,或者至少对这个观察有一个解释?还是确定是虚拟化系统(vmware 与 hyper-v)导致数据库的 CPU 时间存在如此大的差异?

Sti*_*ing 1

如果您还没有这样做,我强烈建议您:

1.> 在主机和来宾上安装正确版本的 Hyper-V 集成服务(如 VMWare Tools)。仅此一项就可以提高性能。

2.> 在 Hyper V 管理器中,禁用处理器上的兼容模式。

3.> 考虑对数据卷使用 SCSI 控制器。

4.> 考虑固定而不是扩展的磁盘大小。

如果您实施这些技术中的任何一种,我很想知道是否获得了任何性能改进。