IIS - 线程池设置的machine.config和web.config区别

Question

我正在IIS 8.5上运行一个ASP.NET 4.5 Web API应用程序。在工作进程下，我发现某些请求被IIS排队，并且从未被服务。这可能是内存泄漏问题。我仍在调查中。在调查期间，我阅读了有关线程池设置的内容。

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

我们有没有其他建议来解决排队问题？

- OpenStack

---

“从未被处理”？如果当前正在处理的请求数量等于线程池中的线程数，并且它们全部死锁，那么请求就永远不会被处理（同时应用程序仍然运行）。 - Gabriel Luci

@GabrielLuci：这个场景很有趣。我的控制器中有多个操作/数据端点。随机地，IIS将其中一些放入队列中。我发现这些调用在队列中保持了长时间，而其他请求正在被服务。一旦一个端点被放入队列中，后续对这些端点的调用将会继续留在队列中。 - OpenStack

你是如何监控这些请求的？在IIS管理器中吗？ - Gabriel Luci

@GabrielLuci：我打开IIS > 在左上角选择根节点（机器名称），然后从右侧窗格中选择工作进程。之后我选择相应的应用程序池，它会显示活动请求。 - OpenStack

你怎么知道正在等待的是同一个请求？那个视图不会自动刷新，也不显示任何请求标识符。你只是看等待时间吗？ - Gabriel Luci

@GabrielLuci：非常好的观点，我刷新了队列。我还使用了“显示全部”按钮来刷新队列。当一切正常时，我会看到队列中的成员（请求）发生变化。我还通过“经过时间”列来跟踪某些请求的等待时间，有时需要几个小时。 - OpenStack

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命令可以帮助您。

- Jokies Ding

Answer 2

这是你的应用程序代码中有某些东西挂起或运行时间过长。

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

在断点处，我在IIS管理器中看到的“状态”是“ExecuteRequestHandler”，因此如果您看到的状态是这个状态，那么请求肯定是由您的应用程序提供服务，并且您的应用程序速度很慢。

如果它只发生在一个特定的API调用中，您可以查找可能的死锁或长时间运行的查询。Jokies的答案可能会帮助您更容易地确定何时以及为什么出现问题。如果它进行SQL查询，您还可以查看SQL服务器上的挂起查询以查看它在做什么。

（旁注：在此之前，我甚至不知道请求监视器的存在，所以这很有趣！） 更新: 您可以在IIS中启用故障请求跟踪来精确定位它的停顿位置。创建一个定时规则(当请求时间超过x秒时记录跟踪)。唯一的缺点是它必须更改您的web.config以启用此功能，因此它会重新启动您的应用程序池，这可能会限制您何时进行此操作。 本文中有关于跟踪长时间运行请求的更多信息，包括您可以修改代码使用Trace.Write将来自代码的信息写入IIS捕捉到的跟踪中。

- Gabriel Luci

---

感谢您的快速回复。我看了一下我拍摄的屏幕截图，可以确认95%的请求处于“ExecuteRequestHandler”状态。但我的理论是，请求未被IIS传递到我的应用程序代码。原因是，一旦我的应用程序收到请求，它首先调用其中一个ActionFilterAttribute，并在OnActionExecuting上记录请求信息。基本上，在应用程序代码能够处理它之前，我们会将每个请求记录到数据库中。在这种情况下，我没有看到任何日志，这意味着OnActionExecuting从未被调用，我的应用程序代码也从未出现。 - OpenStack

我更新了我的回答。你可以使用失败请求跟踪来查看发生了什么以及在哪里。 - Gabriel Luci