LOG_RATE_GOVERNOR等待统计

Question

我在Azure SQL数据库上注意到了这个等待状态，而且我以前从未见过它。我已经尝试过在couple上搜索这个等待数据，但是我还没有想出任何关于这是什么的好信息，尽管我看到了一些关于它可能与超越数据库的Azure性能层有关的信息。

Answer 1

Azure数据库的不同服务层受DTU的限制。Microsoft保证资源的最低级别，它们将其计算为DTU。文献资料提供了DTU的定义，如(强调)：

此数量的资源计算为多个数据库事务单位或DTU，是CPU、内存、I/O (数据和事务日志I/O)的混合度量。这些资源之间的比率最初是由设计为典型的现实世界OLTP工作负载的OLTP基准工作负载确定的。

如果您看到的是LOG_RATE_GOVERNOR等待，那么您将遇到性能层对事务日志I/O施加的限制。

如果此等待对性能产生负面影响，则需要增加服务层，或者更新代码以减少写入操作。如果您有一个IO密集型进程，您可以自己控制它，以便在达到SQL服务层规定的限制之前，让事务日志IOs可以用于其他进程。

我编写了博客文章，在这里我使用DTU计算器来估计每个性能指标是如何结合在一起来影响DTU计算的。您可能会发现这有助于理解不同类型的负载是如何“混合”到DTU限制中的。

Answer 2

当DB正在等待配额写入日志时，会发生Microsoft (这里) LOG_RATE_GOVERNOR。在当前的层次上，进程似乎正在跨越事务日志的速率限制。

尝试识别那些LOG_RATE_GOVERNOR等待所涉及的进程和查询。扩展到使用SSD存储的高级层可以解决这个问题。

如果您使用这文章中提供的机制或使用Query，您还可以识别在执行过程中导致等待的查询。您可能需要重新考虑这些更新、删除、插入以及它们所包含的整个过程的目标。

希望这能有所帮助。