CXPACKET 等待 SQL Server 2008 的性能调整

ato*_*mmc 7 sql-server-2008 sql-server parallelism

我有一个正在处理数百万条记录的 SQL Server 2008 查询。查询在一个由作业每晚运行的过程中。当我第一次将它放在服务器上时,查询可能需要一整天才能运行,但在一周左右的时间内它会下降到不到一个小时——没有我的任何干预。它以某种方式自我修复。

该查询在 tempdb 中运行,在它自行修复之前,当我检查它的性能统计信息时,我发现以下内容:CXPACKET:20,700 秒或 66% 的等待时间。
PAGEIOLATCH:_SH 2,500 或等待时间的 8%。
LOGBUFFER:1500 秒或等待时间的 5% IO_COMPLETION:1500 秒或等待时间的 5%

我尝试调整索引等,当 CXPACKET 为 77% 的等待时间时,上面的统计数据比我第一次运行时有所改进。我阅读了故障排除技巧,其中说我应该将我的 tempdb 拆分为每个 CPU 的一个文件。我有一个双 cpu 32 位 W2K8 系统,所以我将 tempdb 分成 2 个文件,并将每个文件的大小大大增加到 150 GB,每次 10% 自动增长,但它们没有增长,所以我认为大小足够了。

当我在查询运行时查看服务器时,我可以看到 CPU 没有固定并且徘徊在其容量的 <10% 左右。固定的是DISK IO。机器只有一个磁盘。

事不宜迟,下面是导致问题的两个查询(第一个查询曾经是后者的子查询 - 请参阅下面的解释):

insert into #ttcbm(tradeId1, tradeId2)
select distinct tp.tradeid tradeId1, tp1.tradeid tradeId2
from #tradeP tp
join #tradeP tp1    
on tp.cmbId = tp1.cmbId
and tp.qs_plyrid = tp1.qs_plyrid    
and tp.tradeId > tp1.tradeId    
OPTION (MAXDOP 1)


insert into #mergeT(tradeId1, tradeId2)
select distinct tp.tradeid tradeId1, tp1.tradeid tradeId2
from #tradep tp
join #tradep tp1
on tp.cmbId = tp1.cmbId
and tp.tradeid > tp1.tradeId
left join #ttcbm x
on tp.tradeId = x.tradeId1
and tp1.tradeId = x.tradeId2
where 1 = 1
and x.tradeId1 is null
and x.tradeId2 is null
OPTION (MAXDOP 1);
Run Code Online (Sandbox Code Playgroud)

我在每个故障排除提示中添加了 MAXDOP 1 我读到说 CXPACKET 是由并行性引起的,也许它确实有助于减少我的等待,但不像查询修复自身时发生的改进,即从 24 小时到 lest超过 1 小时。

#ttcbm 表的 PK 为 tradeid1、tradeid2 和 #tradep 的 pk 为 (cmbId, qs_plyrid, tradeid) 并且两个表的记录计数都在 100K 到 500k 的数量级。#ttcbm 曾经是后者'insert into #mergeT' 查询的子查询,但是当我读到分离复杂查询可以提高并行性问题时的性能时,我将其分离出来。

mrd*_*nny 10

关于 CXPACKET 有很多误解。CXPACKET 不是问题的根源,而是副作用。当您看到 CXPACKET 的意思是并行查询的线程正在等待该查询的另一个线程执行某些操作时。仅仅因为您看到很多 CXPACKET 等待并不意味着查询有问题,这意味着其他地方存在问题。当您看到 CXPACKET 等待时,您需要查看 SPID 的其他线程并查看除 CXPACKET 之外还有哪些其他等待。另一个等待是问题所在。

对于您的具体问题,运行时间如此疯狂的原因可能是因为 SQL Server 在某些日子生成了不同的计划,因为统计信息已过时(使作业运行时间很长)。然后您手动更新统计信息(或通过作业)或自动统计启动,然后计划变得更好,作业再次快速运行。

一旦您解决了统计问题,您就可以开始查看作业运行缓慢的其他原因。您只有一个磁盘这一事实肯定无济于事。


Jim*_*mbo 5

随着时间的推移,两个原因可能会导致同一查询的改进:

  1. 数据在变化
  2. 查询计划正在改变

您无能为力的数据。要验证查询计划是否正在改进,请尝试在您知道查询以最快速度运行时手动运行查询。保存快速查询计划 在您知道它会很慢的时候运行相同的查询,保存慢速查询 比较两个计划,如果它们不同,您可以强制您的查询使用已保存的计划。 http://technet.microsoft.com/en-us/library/cc917694.aspx

  • 缓存也可能起作用。如果重新启动SQL,会清除缓存,这可以解释为什么一开始需要这么长时间。此外,tempdb 扩展将不得不重新发生,如果您在单个磁盘上,这也会增加时间。 (2认同)