探索性能方案

  • 5 分钟

若要决定如何使用性能工具和功能，请务必通过方案查看 Azure SQL 的性能。

了解常见性能方案

一种用于 SQL Server 性能故障排除的常见方法是检查性能问题是“运行”（高 CPU 使用率）还是“等待”（等待资源）。 下图显示了一个决策树，它用于确定 SQL Server 性能问题是运行还是等待，以及如何使用性能工具来确定原因和解决方案。

运行与等待的关系图。

首先，查看资源整体使用情况。 对于标准 SQL Server 部署，可使用各种工具，例如 Windows 中的性能监视器或 Linux 中的 top。 对于 Azure SQL，可以使用以下方法：

  • Azure 门户/PowerShell/警报

    Azure Monitor 提供集成指标来查看 Azure SQL 的资源使用情况。 还可设置警报来查找资源使用情况。

  • sys.dm_db_resource_stats

    对于 Azure SQL 数据库，可以查看此 DMV 以了解数据库部署的 CPU、内存和 I/O 资源使用情况。 此 DMV 每 15 秒拍摄一次此数据的快照。

  • sys.server_resource_stats

    此 DMV 的行为与 sys.dm_db_resource_stats 相同，但它用于查看 SQL 托管实例的资源使用情况来了解 CPU、内存和 I/O。 此 DMV 也是每 15 秒拍摄一次快照。

  • sys.dm_user_db_resource_governance

    对于 Azure SQL 数据库，此 DMV 将返回当前数据库或弹性池中的资源治理机制所使用的实际配置和容量设置。

  • sys.dm_instance_resource_governance

    对于 Azure SQL 托管实例，此 DMV 返回的信息与 sys.dm_user_db_resource_governance 类似，只不过它是关于当前 SQL 托管实例的。

跑步

如果确定问题是高 CPU 利用率，则这称为运行场景。 运行场景可能涉及通过编译或执行来消耗资源的查询。 使用以下工具来进一步分析：

  • 查询存储

    使用 SSMS 中的资源消耗量最大报表、查询存储目录视图或是 Azure 门户中的查询性能见解（仅限 Azure SQL 数据库）可获得消耗最多 CPU 资源的查询。

  • sys.dm_exec_requests

    在 Azure SQL 中使用此 DMV 可获取活动查询状态的快照。 查找状态为 RUNNABLE 且等待类型为 SOS_SCHEDULER_YIELD 的查询，了解你是否具有足够多的 CPU 容量。

  • sys.dm_exec_query_stats

    可像查询存储一样使用此 DMV 来查找资源消耗量最大的查询。 它仅适用于已缓存的查询计划，而查询存储可提供持久的性能历史记录。 此 DMV 还使你可以获得缓存查询的查询计划。

  • sys.dm_exec_procedure_stats

    此 DMV 提供与 sys.dm_exec_query_stats 非常类似的信息，但可在存储过程级别查看性能信息。

    确定查询消耗量最大的查询后，可能必须检查是否有足够多的 CPU 资源来处理工作负载。 可使用轻型查询分析、SET 语句、查询存储或扩展事件跟踪等工具调试查询计划。

等待

如果问题似乎不是 CPU 资源使用率较高造成的，则可能是涉及等待资源的性能问题。 涉及等待资源的场景包括：

  • I/O 等待
  • 锁定等待
  • 闩锁等待
  • 缓冲池限制
  • 内存授予
  • 计划缓存逐出

要对等待场景执行分析，通常应查看以下工具：

  • sys.dm_os_wait_stats

    使用此 DMV 可查看数据库或实例的最常见等待类型。 这可指导你根据最常见的等待类型执行下一步操作。

  • sys.dm_exec_requests

    使用此 DMV 查找活动查询的特定等待类型，以查看它们所等待的资源。 这可能是等待来自其他用户的锁定的标准阻塞场景。

  • sys.dm_os_waiting_tasks

    对于当前正在执行的特定查询的特定任务，可以使用此 DMV 查找该任务的等待类型，或许可以发现它花费的时间比正常情况长的原因。 sys.dm_os_waiting_tasks 包含一段时间内 sys.dm_os_wait_stats 聚合的实时等待统计信息。

  • 查询存储

    查询存储提供报表和目录视图，可显示查询计划执行的最常见等待的聚合。 必须了解的是，等待 CPU 相当于运行问题。

特定于 Azure SQL 的场景

某些性能场景（包括运行场景和等待场景）特定于 Azure SQL。 其中包括日志治理、工作线程限制、业务关键服务层遇到的等待，以及特定于超大规模部署的等待。

日志治理

Azure SQL 可使用日志速率治理来强制实施针对事务日志使用的资源限制。 可能需要此强制措施来确保资源限制并满足承诺的 SLA。 以下等待类型可能会使用日志治理：

  • LOG_RATE_GOVERNOR：等待 Azure SQL 数据库
  • POOL_LOG_RATE_GOVERNOR：等待弹性池
  • INSTANCE_LOG_GOVERNOR：等待 Azure SQL 托管实例
  • HADR_THROTTLE_LOG_RATE*：等待业务关键和异地复制延迟

工作线程限制

SQL Server 使用工作线程池，不过会限制最大工作线程数。 具有大量并发用户的应用程序可能会接近为 Azure SQL 数据库和 SQL 托管实例强制实施的工作器限制：

  • Azure SQL 数据库具有基于服务层级和大小的限制。 如果超过此限制，新查询会收到错误。
  • 当前 SQL 托管实例使用 max worker threads，因此超过此限制的工作器可能会遇到 THREADPOOL 等待。

业务关键 HADR 等待

如果使用业务关键服务层级，则可能会意外遇到以下等待类型：

  • HADR_SYNC_COMMIT
  • HADR_DATABASE_FLOW_CONTROL
  • HADR_THROTTLE_LOG_RATE_SEND_RECV

即使这些等待可能不会降低应用程序运行速度，你也可能不希望看到它们。 这些等待类型通常是使用 Always On 可用性组所特定的。 业务关键层使用可用性组技术来实现业务关键服务层级的 SLA 和可用性功能，因此这些等待类型是预期类型。 长时间等待可能表示出现瓶颈，例如 I/O 延迟或副本滞后。

超大规模

超大规模体系结构可能会导致一些独特的等待类型，其前缀为 RBIO（可能指示日志治理）。 此外，DMV、目录视图和扩展事件也已得到增强，现可显示页服务器读取的指标。

在下一个练习中，你将了解如何运用你在此单元中获得的工具和知识来监视和解决 Azure SQL 的性能问题。