描述等待统计信息

  • 8 分钟

监视服务器性能的一种整体方法是评估服务器正在等待的内容。 等待统计信息很复杂，SQL Server 具有数百种等待类型，它们监视每个正在运行的线程并记录线程正在等待的内容。

检测和排查 SQL Server 性能问题需要了解等待统计信息的工作原理，以及数据库引擎在处理请求时如何使用它们。

等待统计信息如何运行的屏幕截图。

等待统计信息分为三种类型的等待：资源等待、队列等待和外部等待。

  • 当 SQL Server 中的工作线程请求访问线程当前正在使用的资源时，便会发生“资源等待”。 资源等待的示例包括锁等待、闩锁等待以及磁盘 I/O 等待。
  • 当工作线程空闲并等待分配工作时，便会发生“队列等待”。 示例队列等待是死锁监视和已删除的记录清理。
  • 当 SQL Server 等待外部进程（如链接服务器查询）完成时，便会发生“外部等待”。 外部等待的一个示例是与将大型结果集返回到客户端应用程序相关的网络等待。

可以检查 sys.dm_os_wait_stats 系统视图，以浏览执行的线程遇到的所有等待以及 Azure SQL 数据库的 sys.dm_db_wait_stats。 sys.dm_exec_session_wait_stats 系统视图列出活动等待会话。

这些系统视图允许 DBA 大致了解服务器的性能，并轻松识别配置或硬件问题。 此数据从实例启动时就一直保留，但可以根据需要清除数据以识别更改。

等待统计信息按服务器上的总等待数的百分比进行评估。

按百分比排序的前 10 个等待的屏幕截图。

sys.dm_os_wait_stats 中此查询的结果显示了等待类型，以及每个等待类型的等待时间百分比（等待百分比）和平均等待时间（以秒为单位）的聚合。

在这种情况下，服务器具有 Always On 可用性组，如 REDO_THREAD_PENDING_WORK 和 PARALLEL_REDO_TRAN_TURN 等待类型所示。 CXPACKET 和 SOS_SCHEDULER_YIELD 等待的百分比相对较高，表示此服务器面临一定的 CPU 压力。

由于 DMV 提供了自上次 SQL Server 启动以来累积时间最长的等待类型列表，因此定期收集和存储等待统计数据可以帮助你了解性能问题并将其与其他数据库事件相关联。

考虑到 DMV 为你提供了自上次 SQL Server 启动以来累积时间最长的等待类型列表，因此定期收集和存储等待统计数据可能有助于你了解性能问题并将其与其他数据库事件相关联。

SQL Server 中提供了多种类型的等待，但其中一些是常见的。

  • RESOURCE_SEMAPHORE - 此等待类型表示查询等待内存可用，并可能指示对某些查询授予的内存过多。 通常，长查询运行时甚至超时会观察到此问题。 这些等待类型可能是由于统计信息过期、缺少索引和查询并发过多造成的。

  • LCK_M_X - 频繁发生此等待类型可能表示存在阻塞问题，可以通过更改为 READ COMMITTED SNAPSHOT 隔离级别，或者在索引中进行更改来减少事务时间，或者在 T-SQL 代码中改善事务管理，以解决此问题。

  • PAGEIOLATCH_SH - 此等待类型可能表示索引存在问题（或缺少有用的索引），其中 SQL Server 扫描的数据太多。 或者，如果等待计数较低，但等待时间较长，则可能表示存在存储性能问题。 可以通过分析 sys.dm_os_wait_stats 系统视图中 waiting_tasks_count 和 wait_time_ms 列中的数据来观察此行为，以计算给定等待类型的平均等待时间。

  • SOS_SCHEDULER_YIELD - 此等待类型可能表示高 CPU 利用率，这与大量的大型扫描或缺少索引相关，并且通常涉及大量 CXPACKET 等待。

  • CXPACKET - 如果此等待类型较高，则可能表示配置不正确。 SQL Server 2019 之前，最大并行度默认设置是将所有可用的 CPU 用于查询。 此外，并行的费用阈值设置默认为 5，这可能会导致并行执行小型查询，可能会限制吞吐量。 降低 MAXDOP 并增加并行的费用阈值可减少此等待类型，但 CXPACKET 等待类型也可能表示高 CPU 利用率，通常通过索引优化来解决此问题。

  • PAGEIOLATCH_UP - 数据页 2:1:1 上的此等待类型可能表示页可用空间 (PFS) 数据页上的 TempDB 争用。 对于每个数据文件，每 64 MB 数据有一个 PFS 页。 此等待通常是由于仅有一个 TempDB 文件所致，因为在 SQL Server 2016 之前，默认行为是对 TempDB 使用一个数据文件。 最佳做法是对每个 CPU 核心使用一个文件，最多八个文件。 还必须确保 TempDB 数据文件的大小相同，并且具有相同的自动增长设置，以确保均匀地使用它们。 SQL Server 2016 和更高版本控制 TempDB 数据文件的增长，以确保它们以一致且同步的方式增长。

除了上述 DMV 外，查询存储还跟踪与给定查询相关的等待。 但是，不会以与 DMV 中的数据相同的粒度来跟踪查询存储所跟踪的等待数据，但它可以很好地概述查询正在等待的内容。