Azure SQL 数据库连接问题 - 连接太多？答案

【问题标题】：Azure SQL Database Connectivity Issues - Too many connections?Azure SQL 数据库连接问题 - 连接太多？
【发布时间】：2013-09-06 10:06:51
【问题描述】：

我有一个最近推出的白标网站（同一网站的多个版本）。目前还没有大量的流量——主要是机器人，但每天可能有 800 个用户。除了位于非 Azure 服务器上的管理面板外，它还托管在 Azure 上，并带有一个 Azure 数据库。两个站点都连接到同一个 Azure 数据库。还有一些工作人员角色正在运行以处理数据 - 99% 的时间他们什么都不做，但他们会定期检查。

我总是遇到随机错误，持续几秒钟然后又好了，例如：

从服务器接收结果时发生传输级错误。（提供者：TCP Provider，错误：0 - 现有连接被远程主机强行关闭。）

然而，今天早上，我们遇到了一个更严重的问题。它开始于：

System.ComponentModel.Win32Exception: 现有连接被远程主机强行关闭

这发生在机器人（谷歌、百度、AhrefsBot 和 Wiseguys.nl）正在为网站编制索引时。我从中得到一个或多个错误。然后我得到了：

System.Data.SqlClient.SqlException：服务在处理您的请求时遇到错误。请再试一次。错误代码 40143。当前命令出现严重错误。结果（如果有）应丢弃。

这是在 ExecuteReader 阶段。

10 分钟后，真正的问题来了——这意味着没有人可以登录到管理界面，但是当我测试 Azure 托管网站时，它看起来还不错，尽管机器人仍然会出现错误。问题是：

System.ComponentModel.Win32Exception：等待操作超时

随机连接持续开启和关闭大约一个小时。然后我遇到了另一个问题：

System.Data.SqlClient.SqlException：资源 ID：1。数据库的请求限制为 180，已达到。请参阅“http://go.microsoft.com/fwlink/?LinkId=267637”寻求帮助。

这在最后一小时时断时续地发生 - 主要是工人角色。然后我试图找出是什么占用了所有这些请求，我发现了这个命令：

从 sys.dm_exec_requests 中选择 *

当我反复运行它时，它只返回 1 或 2 个请求。

所以我的问题是： 1) 其他人是否经历过与 Azure 上托管的服务器的相对定期（一次，可能一天两次）暂时断开连接的情况？ 2) 上述事件列表是否表明存在特定问题？当许多管理员同时登录时，这一切都可能发生。 3) 收到 180 限制消息时，如何更好地调试对数据库的请求数？

提前致谢。

【问题讨论】：

标签： c# azure-sql-database connectivity

【解决方案1】：

我在几年前写了这个问题，并收到了关于标题稍作更改的通知。在经历了更多的 Azure SQL 数据库之后，我现在知道了这个问题的答案。为了别人的利益，只是你的数据库设置的层太低了。

Azure 的定价层在性能上存在巨大差异。为了实现这一点，他们限制了很多性能指标，例如CPU 功率、每分钟请求数等。

这意味着，如果您超过您的层级，您的请求将开始排队，因为 CPU 功率/请求量太高而无法处理。这会导致超时，然后请求限制会随着请求等待处理而增加。最终，它达到了数据库基本上崩溃的地步。

我的经验是，较低的数据库级别，例如 S0 和 S1，确实功能不足，不应该用于开发或非常基本的站点之外的任何内容。

Azure 门户中有一些很棒的工具可让您调试数据库的运行情况，例如 CPU 图表、索引顾问和查询性能洞察。

【讨论】：

【解决方案2】：

听起来您在查看此 dm_exec_requests DMV 时走在了正确的轨道上。我怀疑你已经看到了，但是关于 180 油门限制的更多信息是 documented here 并概述了一些关键原因。

如果您感兴趣，我们有一个名为 Cotega 的服务，它可能对您的两个问题都有帮助。首先是我们可以运行所有关键 DMV's against your database 来向您展示正在发生的事情以帮助您分析您的数据库，并且我们还可以在您开始接近您的 throttling limits 时通知您（电子邮件、短信）。

【讨论】：

【解决方案3】：

从服务器接收结果时发生传输级错误。（提供者：TCP Provider，错误：0 - 现有连接被远程主机强行关闭。）

和

System.ComponentModel.Win32Exception: 现有连接被远程主机强行关闭

两者都可以安全地忽略。每当连接被外部中断时，它们就会发生，如果用户在接收响应的过程中关闭浏览器，或者其他网络问题中断连接，就会发生这种情况。还有其他类似的异常可能是由于在检测到该条件时处于活动状态的不同框架代码。抛出这些异常以停止处理请求，因为调用者无论如何都不再监听了。

如果您想跟踪活动请求的数量，您应该创建一个用于所有 SQL 连接的包装器，在连接使用时执行互锁递增和递减（使用 IDisposable），并跟踪高-该值的水印。您可以在特殊的隐藏或管理页面中报告它。这样，即使在问题发生时您无法进入系统，您也可以查看活动连接的最高数量，以确保这不是您的问题。这也可以帮助您发现您是否没有处理所有连接。

【讨论】：