我一直有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开始,但不一定是最大的数据I/O,但随后会下降,然后是高CPU使用率,然后继续进行,没有其他异常活动来解释它。在阅读评论后,我想提到的一件事是,当我们将负载从一个辅助数据库转移到另一个辅助数据库时,遇到这个问题,初始数据库上的所有内容都会降为零,但我们切换到的数据库只会增加到正常的5% - 8%的DTU利用率。如果我们随后将流量移回第一个流量,则第一个流量会再次“卡住”,而另一个流量则会下降到切换前的利用率。它的行为就像缩放设置被删除了一样,但没有迹象表明它发生在门户中。
关于索引重建,我们有在azure计时器触发函数中运行的自动化代码,该函数每天晚上(凌晨)检查不同索引上的碎片,如果有足够的碎片,它就会开始重建。最长的重建大约需要一个小时,大约需要17天才能完成所有索引。如果它们不需要重建,它将跳到下一个。
发布于 2019-01-11 20:55:22
通常,当存在资源密集型执行时,就会发生这种情况。在扩展之前,如果你还没有这样做,我建议你从门户网站检查长时间运行的查询,并打开自动索引。当正在进行索引重建(如果您有这样的维护过程)时,也会出现类似的图表。
发布于 2019-01-11 21:32:45
节流可能是导致此问题的原因。当节流发生时,您通常会看到您所描述的症状,连接超时,性能不佳。
您可以使用以下查询查看连接超时:
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文档以了解如何操作。
https://stackoverflow.com/questions/54140456
复制相似问题