【问题标题】:Recurring Timeout on Sql-AzureSql-Azure 上的重复超时
【发布时间】:2017-05-30 17:33:25
【问题描述】:

在我们的系统上,该系统由使用数据库 sql-azure 的 Web 角色实现,我们在特定查询上遇到反复超时。

这些超时在白天会持续几个小时,然后不再出现。

查询有两个表,行数不是很高(大约 800,000 行),使用主键进行连接。

执行计划没问题,索引使用得当,查询一般需要两秒。

没有 EntityFramework 的测试给出相同的结果。

暂时性故障处理不适用于超时情况。

此行为的原因可能是什么?

【问题讨论】:

  • 你的超时设置是多少?您是否尝试过更高的超时时间?超时是否与建立连接或运行查询有关?如果您的查询是 CPU 密集型的,或者如果 SQL Azure 很忙,则 SQL Azure 可能会减慢您的执行速度(CPU 节流)。
  • 查询 sys.event_log 表可以帮助找到节流或连接问题的证据。
  • 谢谢,一般我都是用默认的超时时间,我试过更高的超时时间,没有效果。超时与查询的执行有关。在视图 sys.event_log 中没有关于超时的日志条目。
  • 这只是突出了 SQL Azure 数据库的一个问题,您在实例上获得了一个数据库。该实例上运行着其他数据库。您正在共享资源(mem/cpu/storage/network),如果该实例上用户数据库的其他用户是坏邻居,那么您无能为力。

标签: azure azure-sql-database


【解决方案1】:

过去我们在使用 SQL Azure 时遇到过类似的问题;经常针对少于 10 行的表运行的查询,甚至是标准的 .Net 成员资格提供程序查询,都因超时而间歇性失败。这通常是当我们的服务几乎没有活动时;主要是在晚上。

在可以安全重试 SQL 超时(通常是读取操作)的常用区域中,我们已将超时异常添加到自定义错误检测策略中,取自 Transient Fault Handling Block;但是正如你所说,这在大多数情况下是不合适的。

到目前为止,我们从 Azure 支持中得到的最好解释是,因为 SQL Azure 实际上是一个由多个客户端使用的共享 SQL Server 实例;如果一个用户执行密集操作,它可能会以这种方式影响其他用户。然而;相信这是不可接受的,我们仍在与 SQL Azure 支持人员联系,以确定限制为何无法阻止此类活动影响我们。

你最好的选择是:

  • 通过论坛或直接联系SQL Azure Support(如果您有支持包)
  • 如果可能的话;尝试设置一个新的 SQL Azure 实例并迁移您的数据库
    • 虽然我们在一个 SQL Azure 实例上间歇性地遇到此问题;我们从未在其他 2 个实例上遇到过这种情况。

作为旁注;我们仍在等待 Azure 支持人员回复我们为什么仍会收到超时异常。

【讨论】:

  • 对此的更新;自从我写这篇文章以来,SQL Azure 已经有了很大的进步,我相信他们已经采取了措施来阻止客户在共享实例之间相互影响。如果您想物有所值,还有Premium dedicated servers。截至 2015 年 4 月(我上次专业使用 SQL Azure),我们不再收到这些间歇性超时问题。
猜你喜欢
  • 1970-01-01
  • 2012-01-26
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-07-08
  • 1970-01-01
相关资源
最近更新 更多