生产站点上的 C# SQL 超时 上下文问题我们所知道的有趣的事情我们肯定迷路了想法堆栈跟踪

如何解决生产站点上的 C# SQL 超时 上下文问题我们所知道的有趣的事情我们肯定迷路了想法堆栈跟踪

上下文

我们正在开发自己的用 C# 开发的 Web 应用程序，并依靠 EF 使用 sql 数据库。
该应用程序托管在 Azure 上的 5 个不同数据中心（云）以及客户的本地服务器上。

问题

我们已经因为 sql 超时错误遭受了几个月的痛苦，主要是从客户的角度来看导致速度缓慢。

我们所知道的

• 这种错误出现在工作时间，周末没有一个错误：所以它似乎与客户在云上的使用有关？

• IIS 应用程序托管在 Windows 服务器上。

• sql 服务器作为 docker 容器托管在同一专用网络上的 Linux 服务器上。

• 我们有一个 Grafana 堆栈来概述我们主要在生产服务器（windows 和 linux）上的资源消耗。

  • 在 Linux 指标上，我们可以看到 cpu 和内存的低使用率似乎也不错：至少，sql 服务器容器正在吃掉所有可能的可用内存，我们已经尝试在 Azure VM 中从 32Gb 迁移到 64Gb调整大小但没有成功...

• 超时错误触发了各种不同类型的 EF 查询：从插入到基本选择表中的一行...

有趣的事情

几天前，一位本地客户在他的服务器（Windows）上安装了我们的产品。他在 VM 之外还有一个 sql 服务器：这是我们的产品数据库存储的地方。该服务器上的应用程序非常慢，我们发现了一些超时错误，就像我们在云中遇到的那样！这是第一次发生在本地服务器上。问题是他的服务器上没有用户负载，因为它是最终用户尚未使用的全新安装。

但更有趣的事情来了：我们试图在客户窗口服务器上安装一个 sql Express Server，以一种比在 VM 外使用他自己的 sql server 更好的方式存储数据库。

结果如下：应用尽可能快，不再超时！

我们肯定迷路了

几个月的调查让我今天发布这个主题，因为我没有更多的想法：

• 我们尝试在查询存储中的 sql Server 中进行调查，以找出哪些查询可能会在数周内导致超时：我们确定了其中的几个并对其进行了改进，但没有帮助。
• 我们尝试增加 VM 大小但没有成功
• cpu、内存和磁盘使用情况似乎很好，即使总是很难确定

想法

• 我们的连接字符串中是否有任何未命中配置可以解释外部 sql 服务器和本地 sql Express 之间的区别？
• 会不会是网络问题？
• 还有别的吗？

堆栈跟踪

Microsoft.EntityFrameworkCore.dbupdateException: An error occurred while updating the entries. See the inner exception for details. ---> System.Data.sqlClient.sqlException: Execution Timeout Expired.  The timeout period elapsed prior to completion of the operation or the server is not responding. ---> System.ComponentModel.Win32Exception: The wait operation timed out
   --- End of inner exception stack trace ---
   at System.Data.sqlClient.sqlConnection.OnError(sqlException exception,Boolean breakConnection,Action`1 wrapCloseInAction)