IIS - 线程池设置 machine.config 与 web.config

Question

我在 IIS 8.5 上运行 ASP.NET 4.5 Web API 应用程序。在工作进程下，我看到某些请求被 IIS 排队并且永远不会被服务。这可能是内存泄漏问题。我还在调查。在调查期间，我读到了thread pool settings。

文章讨论了减少争用的推荐线程设置。文章说在 machine.config 中进行这些更改。我的问题是我可以在 web.config 中进行这些更改吗？

对于解决排队问题，我们还有其他建议吗？

Answer 1

Machine.config 指定此 windows 实例中所有 .Net 应用程序的配置。 Web.config 指定特定应用程序的配置。

如果此问题仅发生在单个 IIS Web 应用程序中，您可以在 Web.config 中指定配置。否则，建议在 Machine.config 中设置。

根据我的经验，如果请求卡在队列中，您的问题应该是应用程序池挂起或性能低下问题。 首先，请检查 IIS 应用程序或系统事件日志中是否记录了任何错误消息。

要解决性能问题，请尝试使用Procdump或调试诊断工具捕获转储文件。

我们需要通过这些转储文件检查这些托管堆栈跟踪。这样我们就可以知道哪个方法或请求变得缓慢或挂起。

有了WINDBG mex扩展，我们就知道了：

1. 正在处理多少个请求
2. 每个线程的状态如何
3. 是否有任何线程被冻结或死锁
4. 如果出现死锁，哪个线程被锁定，死锁的地址是什么。

如果我们需要知道应该在您的服务器中应用哪种配置或解决方案，那么找出根本原因或特征也是必要的。

如果您不知道如何分析转储文件，调试诊断分析工具或WINDBG analyze -v命令会有所帮助。

Answer 2

这是您的应用程序代码中的某些内容挂起或运行时间过长。

IIS 管理器中的请求监视器显示所有当前正在运行的请求，而不仅仅是尚未处理的请求。我通过在 Visual Studio 中运行我已设置为在 IIS 中调试的项目来确认这一点。我在 Visual Studio 中设置了一个断点，并在我的浏览器中发起了一个请求。当它到达该断点时，请求监视器会显示该请求，只要我不继续执行代码，时间就会不断攀升。

当我坐在断点处时，我在 IIS 管理器中看到的“状态”是“ExecuteRequestHandler”，所以如果这是您看到的状态，那么您的应用程序肯定正在处理请求，这是您的应用程序运行缓慢。

如果它只发生在一个特定的 API 调用中，您可以查看您的代码是否存在可能的死锁或长时间运行的查询。 Jokies 的回答可能会帮助您确定更容易的位置和原因（也许）。如果它进行 SQL 查询，您还可以查看 SQL 服务器上的待处理查询以了解它在做什么。

（旁注：在此之前我什至不知道请求监视器存在，所以这很有趣！）

更新：您可以在 IIS 中启用 Failed-Request Tracing 以准确查找它停止的位置。创建定时规则（当请求花费超过 x 秒时记录跟踪）。唯一的缺点是它必须更改您的 web.config 才能启用此功能，因此它会回收您的应用程序池，这可能会或可能不会限制您何时可以这样做。

this article 中有更多关于跟踪长时间运行的请求的信息，包括您可以修改代码以使用 Trace.Write 将代码中的信息写入 IIS 获取的跟踪中。