☰

SQL 性能问题 IA64

tag-icon • tag-icon sql-server performance itanium
SQL 性能问题 IA64

我们的生产中遇到了性能问题。

QA 和 DEV 环境是同一物理服务器上的 2 个实例：Windows 2003 Enterprise SP2、32 GB RAM、1 个四核 3.5 GHz Intel Xeon X5270（4 核 x64）、SQL 2005 SP3（9.0.4262）、SAN 驱动器

产品：Windows 2003 Datacenter SP2、64 GB RAM、4 个双核 1.6 GHz Intel 系列 80000002、型号 6 Itanium（8 核 IA64）、SQL 2005 SP3（9.0.4262）、SAN 驱动器、Veritas Cluster

我看到过多的信号等待百分比（> 250％）和页面读取/秒（> 50）以及页面写入/秒（> 25）偶尔都很高。

我确实在 QA 和 PROD 上测试了这个查询，它具有相同的执行计划，甚至相同的统计数据：

SELECT 
                top 40000000 * 
INTO 
                dbo.tmp_tbl
FROM
                dbo.tbl
GO

扫描计数 1、逻辑读取次数 429564、物理读取次数 0、预读读取次数 0、lob 逻辑读取次数 0、lob 物理读取次数 0、lob 预读读取次数 0。

然而，正如你所见，这只是合乎逻辑的解读：QA：0:48 Prod：2:18

所以这看起来像是一个与处理器相关的问题，但是我不确定下一步该怎么做，有什么想法吗？

谢谢，

亚伦

答案1

这是由两个问题引起的 - 产品和 QA 之间的索引不同以及 maxdop 配置不正确。

答案2

生产服务器上还有其他事情发生吗？看起来 QA 服务器只运行这个查询，而生产系统必须满足 CPU 要求，同时运行其他查询。elapsed_time 和 worker_time在 QA 和 Prod 中进行比较？

另外，确保计划完全相同，包括 DOP。

答案3

对于您可能在 SAN 上调查的事项，我有几点建议：

  • 您是否看到生产 SAN 上有大量页面 I/O 闩锁等待？

  • 数据库日志是否位于繁忙的共享卷上？

在前一种情况下，可能存在与 SAN 控制器相关的 SAN 配置或其他性能问题。我曾在 IBM shark 硬件上看到过这种情况；迁移到 DS8000 后，问题得到了很大缓解。

在后一种情况下，您可能会遇到随机寻道中断日志写入活动的问题。日志写入是一个主要顺序的过程，包含大量小的顺序写入。在安静的磁盘上，这很快，因为磁盘访问模式大多是顺序的。在繁忙的磁盘上，其他磁盘流量将顺序日志写入转变为随机写入，速度要慢得多。这可能会使日志驱动器成为严重的性能瓶颈。

请注意，SQL Server 要求在事务提交之前将日志写入刷新到磁盘，并且大多数 SAN 供应商都已加入认证计划，保证控制器将遵守此标准。这意味着，如果您的日志驻留在繁忙的共享卷上，无论多少缓存内存都无法缓解此问题。

答案4

“所以这看起来像是一个与处理器相关的问题，但是我不确定下一步该怎么做，有什么想法吗？”

在我看来，3.5GHz Core 2 架构 CPU 可能比 1.6GHz Itanium 快 100%（Intel 80000002 系列不是最初的 Itanium 2 系列吗，Fanwood 或 Madison？）这似乎并不奇怪。如果您需要更快的速度，可以考虑升级 CPU，例如升级到 x5600 系列 Xeon。

相关内容