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

Question

我们正在将虚拟化数据库服务器从旧的 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 时间存在如此大的差异？

Answer 1

如果您还没有这样做，我强烈建议您：

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

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

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

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

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