应用程序切换到实时 URL 导致数据库使用过多

Posted 2023-03-24

【中文标题】应用程序切换到实时 URL 导致数据库使用过多

【英文标题】：Application switched to live URL causes excessive DB usage

【发布时间】：2017-03-15 00:19:03

【问题描述】：

这里非常非常奇怪的问题...提前为文字墙道歉。

我们有一套在 EC2 实例上运行的应用程序，所有应用程序都连接到 RDS 实例。

我们在同一台 EC2 服务器上托管暂存和生产应用程序。

对于其中一个应用程序，一旦将暂存应用程序移至 prod，就会打开超过 250 个与数据库的连接，从而导致 RDS 实例最大限度地使用 CPU 并使整个套件变慢。暂存应用程序本身不存在此问题。

可以通过我们的 Octopus 设置部署应用程序以及物理复制粘贴 BIN/Views 文件夹从暂存到实时复制该问题。

连接是即时的，在不到一分钟的时间内将 CPU 使用率提高到 99%。

注意事项...

运行how to see active SQL Server connections? 将显示批量连接，它们都没有登录名。

FE 服务器上的资源监视器将列出所有来自 IIS 的连接，似乎扫描所有出站端口，并尝试在其端口上连接到数据库服务器。 FE服务器地址和DB服务器地址分别涂黑。所有连接中只有一个 sn-p。

该应用需要用户登录才能执行 99.9% 的任务。有一种公开的“忘记密码”方法已更新为接受用户名或密码。表单结构或表单操作 URL 没有变化，只是在后面额外检查。

其他变化是围绕数据的显示方式和特定条件下的付款限制。两者都需要登录。

我尝试过的事情......

新的应用程序池 只要给它几天时间就可以忘记这曾经发生过的事情 不使用八达通发布 检查版本之间更新的所有区域以查看连接是否未正确关闭。

真的不知道发生了什么。这是我第一次看到这样的事情。特别奇怪的是，暂存很好，但是另一个 URL/连接字符串上的同一个应用程序却失败了。

我能想到的唯一想法可能是某种正在轮询公共表单的抓取工具，但这没有任何意义，因为为什么当前应用程序没有发生这种情况......

AWS 中有什么东西可以监控正在进行的调用吗？我隐约记得 NewRelic 中的某些东西能够做到这一点。

欢迎任何建议和/或类似经验。

编辑。

问题当天（昨天）的日志中没有任何未解决的问题 没有与所有出站请求匹配的传入流量 应用程序在启动时不执行初始化

更新...

我们的大多数查询都使用 ADO。更新了查询以从不同的表中获取数据。方法名称和参数没有改变，只是查询的主体。如果我使用 sys.dm_exec_sql_text 查看发送到数据库的内容，我可以看到这是在数百个连接中的每个连接中发送的更新查询。虽然它们都显示为挂起...关于查询发送到服务器的方式没有任何变化，只是查询本身的主体...

【问题讨论】：

检查您的 IIS W3C 日志。您是否有大量与这些请求相对应的入站流量？还是很安静？你有没有看到任何可疑的东西，比如重定向循环？

现在运行日志。似乎没有任何入站流量。当我们再次切换到测试问题时，DB 连接数很低，例如 15。将检查重定向循环...

所以也许你有一个启动问题。应用程序是否在其初始化例程中访问数据库（例如，获取设置）？我猜它正在倒下并一次又一次地重试。您可能有某种特定于环境的配置，或者可能是权限不正常。

谢谢约翰。没有执行初始化。即便如此，它也会在登台数据库上失败吗？两个数据库是平等创建的。

【参考方案1】：

因此，更新中发布的其他查询之一破坏了它。我们只恢复了那个查询并部署了一个新版本，这很好。

奇怪的是，它是以一种或另一种形式在整个套件中运行的。但只是在任何非暂存的负载下死亡，这就是为什么我认为这将是最后一个看的地方。