收集等待统计

Question

我们目前使用一个监控工具，它通过等待任务的数量或总等待时间向我们显示我们的最高等待统计数据。以下是按等待任务数量以及每个任务的等待时间的等待统计数据。

我们有用户抱怨系统速度变慢，但服务器的指标在磁盘 IO、内存和 CPU 方面似乎很好。有谁知道 PREEMPTIVE 等待是否有问题？

Number of waiting tasks
SOS_SCHEDULER_YIELD
PAGELATCH_EX
PAGELATCH_SH
PREEMPTIVE_XE_CALLBACKEXECUTE
PREEMPTIVE_XE_GETTARGETSTATE
PREEMPTIVE_XE_SESSIONCOMMIT

Average wait per task
PAGEIOLATCH_SH
PREEMPTIVE_XE_GETTARGETSTATE 

更新：
我从 Paul Randal 运行了一个类似于您发布的查询并得到以下信息：

WaitType    Wait_S  Resource_S  Signal_S    WaitCount   Percentage  AvgWait_S   AvgRes_S    AvgSig_S
PREEMPTIVE_XE_GETTARGETSTATE    9704.81 9704.81 0.00    604647  44.60   0.0161  0.0161  0.0000

我知道这不是很好，但基本上这种等待类型占所有等待类型的 %44.60。此外，由于这种类型没有信号等待，因此这表明没有 CPU 压力，而是在等待其他资源。不知道我是如何推断出该资源是什么的。

这也是 SQL 2012 SP1

更新2 此处请求的 AS 是您查询的结果。关于扩展事件，唯一运行的会话是我刚刚注意到的默认 system_health 1 和 2 SharePoint 会话，它们必须默认放置在那里。我可能会关闭这些，我想知道这些是否会导致问题。

有趣的是，我的 PREEMPTIVE_XE_GETTARGETSTATE 似乎不在此列表中。

wait_type   wait_time_ms    signal_wait_time_ms resource_wait_time_ms   percent_total_waits percent_total_signal_waits  percent_total_resource_waits
SP_SERVER_DIAGNOSTICS_SLEEP 300014  355508314   0   24.621089361251698  99.883069863550302  0.000000000000000
MSQL_XP 96782   0   4268999 0.295653861591811   0.000000000000000   0.295653861591811
ASYNC_IO_COMPLETION 56193   64  345552  0.023935987107964   0.000017981341700   0.023931554722962
BACKUPTHREAD    41100   6850    265025  0.018828979257262   0.001924565478840   0.018354575549998
LCK_M_U 40500   71  41030   0.002846491499596   0.000019948050948   0.002841574322484
PWAIT_ALL_COMPONENTS_INITIALIZED    31422   0   94205   0.006524262955146   0.000000000000000   0.006524262955146
XE_LIVE_TARGET_TVF  28050   0   33458   0.002317167771915   0.000000000000000   0.002317167771915
LCK_M_X 4027    50  29195   0.002025392177944   0.000014047923203   0.002021929377161
SQLTRACE_INCREMENTAL_FLUSH_SLEEP    4018    613 355390660   24.612983567922965  0.000172227538471   24.612941113985366
CXPACKET    3756    1   14755   0.001021941767062   0.000000280958464   0.001021872511047

Answer 1

根据preemptive_xe_*我的理解和可以找到，等待类型与扩展事件相关联。考虑到这一点和你的第一句话：

我们目前使用一个监控工具，它通过等待任务的数量或总等待时间向我们显示我们的最高等待统计数据。

我会开始将您的监控工具视为罪魁祸首。然而，由于你从 Paul 的脚本中得到的数据显示平均等待时间很低，我现在不会太担心。

我认为您可能忽略的主要挑战是您的用户告诉您系统/应用程序速度变慢。大多数将始终指向数据库/服务器作为罪魁祸首。当有人告诉我“系统的哪个部分很慢”时，我的下一个一般问题。如果他们告诉我诸如页面加载缓慢之类的事情，并且他们实际上没有执行任何临时报告或查询，我会要求他们与服务器人员或应用程序管理员核对以确保没有其他问题。然后，当他们这样做时，我将检查数据库服务器的性能。但是，正如您所展示的，如果 XE 等待类型是唯一高于 10% 左右的等待类型，我认为问题不在于数据库服务器。

如果您想找到该等待类型的罪魁祸首，您可以开始查询sys.dm_os_waitting_tasks，这将显示session_id正在发生的等待。您还可以使用sp_WhoIsActive更轻松地获取类似信息。我敢打赌，您会发现它是与您的监控工具相关联的会话。