等待时间怎么可能高于时钟时间？

Question

当我使用 sp_BlitzFirst 跟踪等待时，我得到以下详细信息：

<?ClickToSeeDetails -- 
For 20 seconds over the last 5 seconds, SQL Server was waiting on this 
particular bottleneck.


 -- ?>

应该是“过去 5 秒内 20 次”吗？发现是 CLR_SEMAPHORE。

Answer 1

不 - 等待统计数据可以（并且通常情况下，将）总计超过服务器本身花费的物理时间。

想象一下这样一种情况，其中 2 个单独的线程花费相同的秒数等待某个资源 - 您将有 2 秒的等待时间为 1 秒的时钟时间。

每个线程都有它自己的等待 - 该消息告诉您该特定资源的 20 秒等待时间发生在时钟时间的最后 5 秒内。

或者换句话说，每个内核可以同时运行多个查询，多个内核加起来可能会导致更多的等待。也就是说，单位实际上是线程·秒，而不是秒。

Answer 2

通过一个例子来工作也可能会有所帮助。考虑工人最常见的三种状态：

RUNNING = Worker 当前正在非抢占式或抢占式运行。

RUNNABLE = 工作线程已准备好在调度程序上运行。

SUSPENDED = 工作线程当前被挂起，等待事件向其发送信号。

处于以下状态的工人 RUNNING可以产生等待时间。例如，如果 worker 需要在 OS 中而不是在 SQLOS 中运行代码，那么它可能会进入抢占式或外部等待。在此期间，它将在其关联的 CPU 上运行代码，但仍会产生等待时间。

状态为 的工人RUNNABLE可以产生等待时间（据我所知他们总是这样做）。如果 worker 被告知资源可用，那么它可能会根据上次等待累积信号等待时间。如果工人用尽了之前的 4 毫秒量子，那么它可能会累积SOS_SCHEDULER_YIELD时间，等待时间。

状态为 的工人SUSPENDED可以产生等待时间。考虑一个等待锁的工人。它将产生等待时间，直到它发出信号表明它需要的锁资源可用。一些暂停的工作人员不会产生等待时间，包括那些与任务无关的工作人员。

我的桌面有四个逻辑核心，所以默认的最大工人数是512。这几乎肯定是不切实际的，但在这台机器上，如果我设法让每个工人同时等待某事，理论上我可以每秒产生 512 秒的等待时间。随着核心/工人数量的增加，这个数字可能会更高。

即使您没有对 SQL Server 运行任何查询，您也可以看到每秒等待的时间超过一秒。在我的机器上，以下查询似乎在 9-14 行之间生成：

SELECT [state], last_wait_type, wait_started_ms_ticks
FROM sys.dm_os_workers
WHERE [state] IN ('SUSPENDED', 'RUNNABLE')
AND task_address IS NOT NULL
AND wait_started_ms_ticks <> 0
AND wait_started_ms_ticks >= start_quantum;

我可以拍摄自上次重新启动服务器以来的总等待时间快照，并在等待 10 秒后将其与新的总时间进行比较：

DECLARE @start_wait_time_ms BIGINT;

SELECT @start_wait_time_ms = SUM(wait_time_ms)
FROM sys.dm_os_wait_stats
WHERE wait_type <> 'WAITFOR';

WAITFOR DELAY '00:00:10';

SELECT SUM(wait_time_ms) - @start_wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_type <> 'WAITFOR';

有时数学会奏效。我上次运行它时，增量为 101339 毫秒。换句话说，我每秒有超过 10 秒的等待时间来自系统任务。