如何找到 IIS/SQL 超时的原因？答案

【问题标题】：How do I find the cause of an IIS/SQL timeout?如何找到 IIS/SQL 超时的原因？
【发布时间】：2020-11-25 13:53:15
【问题描述】：

我有一个位于 IIS 上的 Web 服务，几个月来一直运行良好，但现在我遇到了超时，我不知道如何诊断问题所在。

客户端将“心跳”消息中的基本信息发送到 IIS，然后 IIS 在 SQL 数据库中更新这些信息（在不同的服务器上）。野外有 250 个客户端，所有客户端每 5 分钟发送一次他们的心跳...所以表中只有 250 行，并在用于更新的列上有适当的索引。

通常只需要 50-100 毫秒即可完成更新，但从上周开始，您可以看到 IIS 日志中的响应时间增加了，而且我也遇到了超时。

设置没有任何改变，所以我不知道我在寻找什么来确定原因。我得到的错误是：

System.ServiceModel.FaultException：更新时出错条目。有关详细信息，请参阅内部异常。发生错误在更新条目时。请参阅内部异常 details.Execution Timeout 已过期。超时时间过去之前操作完成或服务器没有响应。这语句已终止。等待操作超时

关于从哪里开始寻找的任何建议？我确实在 IIS 中启用了失败的请求日志跟踪，但如果我完全诚实的话，我不知道这一切意味着什么。成功的请求和失败的请求之间的区别在于请求日志在“AspNetStart”条目之后停止。

谢谢！标记

【问题讨论】：

这是 IIS 和 SQL Server 之间的唯一交互，还是有其他查询正常工作并且这是唯一有问题的查询？
还有其他查询正常工作，但也有其他服务偶尔会出现超时或握手错误。不一致。
是否还有其他东西使用该表 - 即是否有其他东西锁定了它，从而阻止您的查询被及时处理？
不，只有这个网络服务使用那个表。
您需要确定是 SQL Server 问题、IIS 问题还是基础设施问题（例如不可靠的以太网电缆）。由于其他查询正在工作，我认为这不是电缆。对于第一个，假设您对 SQL Server 有足够的访问权限，也许搜索“sql server query has become slow”会给您一个调查的地方。

标签： sql-server entity-framework web-services iis

【解决方案1】：

服务逐渐或突然变慢的原因有很多。糟糕的代码结构会导致服务器上的内存泄漏等问题，足够小它们不会真正出现或在测试期间引起问题，但是当运行数周/数月时开始堆积。如果这是一项面向公众的服务，或者具有指向公众服务的链接，那么未经授权的请求可能会针对您的服务器。

看点：

这种情况发生在一天中的特定时间还是全天？

这是在多个用户同时发送更新时开始出现的负载问题吗？ 250 个用户并不多。用户数量在过去几个月中是否有所增长，还是从一开始就相对稳定？

Web 服务器和数据库服务器上的内存和 CPU 使用情况如何？

这是检查任一服务器是否处于相当负载状态的第一条线索。从那里您可以调查为什么它可能处于负载之下，或者它是否可能需要更多的咕噜声来处理负载。查看正在运行的进程。如果这些服务器是由 IT 部门管理的，那么一些罪魁祸首可能包括病毒扫描程序占用资源之类的东西。（即过去几个月的政策变化导致服务器负载增加）

您的数据库设置为哪种恢复模式？
您的 Tx 日志（.mdx 文件）的大小是多少
您是否定期进行数据库备份和索引维护？

这是新项目容易忘记的。空数据库很小，没有记录 Tx Log 历史记录，但随着时间的推移，Tx Log 在后台默默增长，尤其是在完全恢复的情况下。随着时间的推移，较大的 Tx 日志可能会导致性能下降，尤其是在需要扩大日志文件的情况下。要检查的一件好事是日志文件是否设置为按字节数或百分比增长。百分比是我相信的默认值，但这可能会导致指数“增长”时间/空间问题，因此最好将其设置为每次增长的固定大小。您需要定期备份以允许重置 Tx 日志。如果备份之间的日志大小保持一致，最好不要缩小文件。

一天内插入或更新了所有表中的多少条记录？

这对于构建数据库在备份之间的一天中将跟踪多少的图片很重要。您可能有 250 个客户端，但每个心跳都可能更新一行并插入其他行。

对于插入记录的 PK，您使用什么？（整数与 UUID）如果使用 UUID，您使用的是 NEWSEQUENTIALID() 还是 NEWID()/Guid.New()？

如果做得不好，GUID 可能会成为索引的定时炸弹。 GUID 与NEWID() 或Guid.New() 结合使用会在插入行时导致相当大的索引碎片。如果 GUID 对客户端不可见，您应该使用 NEWSEQUENTIALID()。如果 ID 是通过代码设置的，那么您可以找到一些实现来生成顺序 GUID。（这是重新排列组成 GUID 的部分的问题）定期维护索引是在索引字段中使用 UUID 列的要求。

您是否在 Web 服务中使用依赖注入？
执行更新的 DbContext 的生命周期范围是多少？

如果 DbContext 的生命周期范围设置不正确，这对 Web 服务器来说是一个潜在的定时炸弹。您希望 DbContext 的存活时间不超过所需时间。最大生命周期范围应设置为 PerRequest。例如，为 Singleton 设置的 DbContext 将跨请求跟踪实体。 DbContext 跟踪的实体越多，读取和更新操作就越慢。如果 Web 服务器内存使用量不断攀升，这可能是罪魁祸首。

您是否正在运行 SQL Profiler？

在没有其他任何东西接触数据库的测试环境中，使用 SQL Profiler 通过应用程序运行场景可以揭示潜在问题，例如由于延迟加载等原因而启动的意外查询。对于一项操作，您可能期望运行一个或少量查询，结果却发现几十个甚至几百个。将这个乘以并发请求，你就有了一个让数据库服务器说“坐下来等待，该死！”的秘诀。 :) 应调查基于正在运行的代码的任何您不期望的查询，以了解急切加载关系或实现投影。（推荐以获得最佳性能）

网络服务器会定期重启吗？

对于一些棘手的调试问题和内存泄漏，有时最简单的“修复”是安排 Web 服务器的定期重启。这是一种 hack，但与试图追踪内存泄漏或修复随时间变慢的低效代码的巨大成本相比，它是一种廉价而有效的修复方法。（至少在您研究解决问题和优化代码的选项时）

这应该让您开始检查服务和数据库。

【讨论】：