Ran*_*der 4 azure-sql-database
我注意到 Azure SQL 数据库上的这个等待统计信息,我以前从未见过。我试过在谷歌上搜索这个等待统计数据,但没有找到关于它是什么的任何好的信息,尽管我看到一些提到它可能与超过为数据库设置的 Azure 性能层有关。
Azure SQL 数据库的不同服务层受 DTU 限制。Microsoft 保证最低级别的资源,他们将这些资源计算为 DTU。该文档提供了 DTU 的定义(强调我的):
此资源量计算为数据库事务单元或 DTU 的数量,并且是 CPU、内存、I/O(数据和事务日志 I/O)的混合度量。这些资源之间的比率最初由OLTP 基准工作负载确定,该工作负载设计为典型的现实世界 OLTP 工作负载。
如果您看到LOG_RATE_GOVERNOR
等待,那么您就遇到了性能层对事务日志 I/O 施加的限制。
如果此等待对性能产生负面影响,则您需要增加服务层,或更新代码以执行更少的写入。如果您有一个 IO 密集型进程,您可以自己限制它,以便在达到 SQL DB 服务层施加的限制之前让事务日志 IO 可用于其他进程。
我写了一篇博客文章,其中我使用DTU 计算器来估计这些性能指标中的每一个如何组合以影响 DTU 计算。您可能会发现这有助于理解不同类型的负载如何“混合”到 DTU 限制中。
归档时间: |
|
查看次数: |
2099 次 |
最近记录: |