Question

我遇到了Azure SQL的问题，通常会在随机时间内最大化DTU，而查询负载没有变化。我通常看到dataIO发生了巨大的跃迁，紧接着是CPU的跃迁。然后，DataIO将消退，但CPU使用率似乎陷于阻塞，响应时间变得过长，以至于查询代码开始超时。我发现纠正问题的唯一方法是放大或缩小，让它稳定下来，然后再缩放回原始设置。

我们正在使用S4大小，但是，S2足够了，除非在数据中心维护期间。正如我提到的那样，当它“卡住”时，我缩小到S2，使其稳定，然后再回到S4，一切恢复正常。我们还运行4个只读副本，并且当它检测到问题时，代码会在副本之间切换，这使我们有时间进行缩放技巧并使事情恢复正常。直到读/写横摆，然后没有地方可以切换到这个位置时，此方法才能很好地工作。

我们花了无数小时来介绍最佳实践并获得Azure支持，有一次我们被告知将有一个补丁来解决它。看来他们做了几个月的工作，我们只会看到它停留约15分钟，然后恢复正常，但是在最后一个月之内，它又回到了这种状态，直到我们扩展为止。在这些期间，我想重新启动服务器，但是扩展似乎是下一个最好的选择。

Azure SQL 24hr graph, running normal, DTU jump and stuck, then after scale return to normal

有人知道这可能是什么原因，以及在服务器级别真正进行了什么扩展？

编辑：

这些事件通常以高但不一定是最大的数据I / O开始，但随后下降，然后是CPU使用率高，而这种情况一直持续下去，没有其他异常活动来解决。在阅读评论之后，我想提到的一件事是，当我们将负载从一个遇到此问题的辅助数据库转移到另一个数据库时，初始数据库上的所有内容都降至零，但是切换到该数据库后的内容只会增加到正常值5％-8％的DTU利用率。如果我们随后将流量移回第一个，则第一个将再次“阻塞”，而另一个下降到交换前的利用率。它的行为就好像比例尺设置被降低了，但是没有迹象表明它在门户网站中发生过。

关于索引重建，我们在天蓝色的计时器触发的函数中运行了自动化代码，该函数每天晚上（清晨）检查另一个索引上的碎片，如果有足够的碎片，它将开始重建。最长的重建运行大约一个小时，并且所有索引需要大约17天的时间。如果不需要重建它们，它将跳到下一个。

Answer 1

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

Answer 2

节流可能是此问题的原因。节流时，通常会看到您描述的症状，连接超时，性能不佳。

您可以通过以下查询查看连接超时：

select * 
from sys.event_log 
where event_type <> 'connection_successful' and
start_time >= CAST(FLOOR(CAST(getdate() AS float)) AS DATETIME)
order by start_time desc

以下查询会告诉您何时需要扩展。

SELECT     
(COUNT(end_time) - SUM(CASE WHEN avg_cpu_percent > 80 THEN 1 ELSE 0 END) * 1.0) / COUNT(end_time) AS 'CPU Fit Percent',
(COUNT(end_time) - SUM(CASE WHEN avg_log_write_percent > 80 THEN 1 ELSE 0 END) * 1.0) / COUNT(end_time) AS 'Log Write Fit Percent',
(COUNT(end_time) - SUM(CASE WHEN avg_data_io_percent > 80 THEN 1 ELSE 0 END) * 1.0) / COUNT(end_time) AS 'Physical Data Read Fit Percent'
FROM sys.dm_db_resource_stats
--service level objective (SLO) of 99.9% <= go to next tier

当avg_log_write_percent为100％或接近100％时，将发生节流。在启动IO密集型工作负载之前，尝试实施扩展到高级层。

尝试对您的IO工作负载实施批处理，以控制这些DTU峰值。请阅读this文档以了解操作方法。

Azure SQL DTU跳起来并被“卡住”

2 个答案: