时间戳

首页 > 解决方案 > Azure SQL DTU 跳起来并“卡住”

azure - Azure SQL DTU 跳起来并“卡住”

问题描述

我一直在使用 Azure SQL 时遇到问题，经常在随机时间最大化 DTU，而查询负载没有变化。我通常会看到 dataIO 的大幅跃升，紧随其后的是 CPU 的跃升。DataIO 然后会消退，但 CPU 使用率似乎会卡住，响应时间会变得过长，以至于查询代码开始超时。我发现解决问题的唯一方法是放大或缩小，让它稳定，然后缩小到原始设置。

我们正在运行 S4 大小，但是，除非在似乎是数据中心维护期间，否则 S2 就足够了。正如我提到的，当它“卡住”时，我缩小到 S2，让它稳定，然后回到 S4，一切都恢复正常。我们还运行 4 个只读副本，当它检测到问题时，代码会在副本之间切换，这让我们有时间进行扩展技巧并使事情恢复正常。这工作得很好，直到读/写横向移动，然后就没有地方可以切换了。

我们已经花费了无数个小时来研究最佳实践和 Azure 支持，有一次我们被告知会有一个补丁来处理它。似乎他们做了几个月的事情，我们会看到它只卡住了大约 15 分钟，然后恢复正常，但在上个月它又回到了这种状态，直到我们扩大规模。在这些期间，我想重新启动服务器，但扩展似乎是下一个最好的事情。

Azure SQL 24小时图，运行正常，DTU跳卡卡住，缩放后恢复正常

有谁知道这可能是什么原因，以及缩放在服务器级别上的真正作用是什么？

编辑：

这些事件通常以高数据 I/O 但不一定是最大数据 I/O 开始，但随后下降，随后是高 CPU 使用率，只是继续进行，没有其他异常活动来解释它。在阅读评论后，我只想提一件事，当我们将负载从一个遇到此问题的辅助服务器移动到另一个辅助服务器时，初始数据库上的所有内容都降至零，但我们切换到的数据库只会增加到我们的正常值5% - 8% DTU 利用率。如果我们随后将流量移回第一个，则第一个会再次“卡住”，而另一个会下降到切换前的利用率。它的行为就像比例设置被下拉，但没有迹象表明它发生在门户中。

关于索引重建，我们在 azure timer 触发函数中运行了自动代码，该函数每晚（凌晨）检查不同索引上的碎片，如果碎片足够多，它就会开始重建。最长的重建运行大约一个小时，大约需要 17 天才能完成所有索引。如果它们不需要重建，它将跳到下一个。

标签： azureazure-sql-databaseazure-sql-server

解决方案

通常，当执行资源密集型时会发生这种情况。在扩展之前，如果您还没有这样做，我建议您从门户检查长时间运行的查询并打开自动索引。当正在进行索引重建（如果您有这样的维护过程）时，也会出现类似的图表。

推荐阅读