Azure SQL数据库DTU计算利用率最大

Question

我有一个Azure SQL数据库，它已经从0-3% (avg)之间的较低的DUT基线发展到现在利用率达到最大的100%。

这是一个LOB应用程序，我们需要了解是什么导致了这样的利用率最大化。服务器是在标准的200个DTU，而不是在一个弹性池。

我看过Azure门户中的Query performance insight，虽然有一些长时间运行的查询，但在过去的一周中，头号用户只代表0.3%的CPU和0.23%的数据IO。

有人能在这里提供一个诊断这个问题的好策略吗？

Answer 1

罪魁祸首只占CPU的0.3%

DTU是一个CPU和IO时间包，所以您很可能有查询执行大量的读IO (索引或表扫描最有可能)或写IO。

突然的变化可能是因为：

• 一个新的应用程序发行版，它具有新的SQL活动，还没有在与生产数据类似的数据上进行测试。寻找消耗大量IO的长时间运行语句。这里的解决方案要么是改进这些查询和/或支持它们的索引选择。
• 数据大小的显着变化(突然或随着时间的推移)意味着您的公共工作集不再方便地安装在RAM中，这意味着缓冲池正在崩溃，导致了额外的IO工作。
• 数据形状的显着变化(突然或随着时间的推移)意味着查询计划者在选择最优路径时遇到困难。如果有很长一段时间没有这样做，刷新索引统计数据有时会有所帮助。
• 如果您的应用程序允许用户定义报告或过滤器，他们可能已经创建了与第1点具有相同效果的东西(您可能会以同样的方式检测到这一点)。
• 活跃用户的突然涌入，或现有用户突然变得更加活跃。请检查您的应用程序日志。

或者是上面的一些混合物。

您没有说明您的数据库当前的服务级别(服务层、服务级别，它在池中吗，如果是的话池的层/级别和每个DB设置)--将其编辑成您的问题是个好主意。

对于短期修复，增加该数据库的DTU分配。如果负载主要是IO，那么考虑从一个标准转移到一个高级层(虽然它们没有公开记录DTU是如何组成/判断的，但是一个高级DTU的IO比一个标准的IO高一个数量级，所以从标准的100到高级125有时比从标准的100转到标准的400要有效得多，但成本更低)。

在问题

中的额外信息之后更新

头号罪犯..。数据IO为0.23%

屏幕抓取是按CPU排序的显示，所以CPU使用的头号违法者显然没有使用太多的IO。但是，如果您正在寻找导致大量IO的进程，那么您需要按IO进行排序，因为这可能也不消耗CPU (您的CPU分配可以等待IO完成)。

尽管从这个显示中值得检查这四个人的行为是否尽善尽美，尤其是第四个，平均每次执行要花22.5分钟。这可能是由于锁定问题，因此没有显示多少CPU或IO活动，尽管在任何情况下都值得研究。

在过去的一周。

根据最上面的图表，你的问题只是几天前才开始的，所以看整周不太可能那么有意义。“性能洞察力”选项卡允许您放大比这更精细的内容。