.NET 应用程序失败 - 通过回收应用程序池解决答案

【问题标题】：.NET Application Failing - Resolved by Recycling App Pool.NET 应用程序失败 - 通过回收应用程序池解决
【发布时间】：2024-05-17 02:05:01
【问题描述】：

我正在查看一个 .NET ASP 应用程序（从支持方面 - 我没有对其进行编程）。

它间歇性挂起 - 网页无法打开。回收应用程序池可以解决此问题。

我可以在事件查看器中看到条目说明

进程服务器应用程序池“wsfrappPool”在关闭期间超出了时间限制。来自 W3SVC 的进程 ID 是“9396”。

我也能看到

服务应用程序池“AeXRSVaultPool”的进程 ID 为“6804”的工作进程已请求回收，因为该工作进程已达到其允许的处理时间限制。

我正在寻求有关如何追踪导致挂起的原因并防止其再次发生的建议。我可以使用性能计数器来跟踪它吗？这些事件查看器条目是否相关？

【问题讨论】：

【解决方案1】：

检查 IIS 日志以查看应用程序崩溃前的最后几个请求。这可能会提示您哪些页面可能导致问题。

我在使用 .net 1.* 时遇到过很多这样的问题，主要是由于内存不足或工作进程膨胀到超过 1GB 的内存。（有很多大文件上传，一些明确的 GC.Collect() 调用有所帮助 - 不好，但需要修复）自 2.0 以来，我没有遇到过这种问题（大文件和所有，没有 GC.Collects） .

事件查看器事件可能描述了您回收池的操作。

【讨论】：

感谢 StingyJack。它托管在 1.1.4322 中。应用程序池中仅托管一个站点。这个应用程序处理大量文件上传。你知道任何性能计数器来跟踪它吗？是否有任何 web.config 设置可以提高性能？
不，性能计数器并没有真正的帮助，如果您没有源代码或无法修改应用程序，您就有点搞砸了。您可能拥有的唯一选择是将站点更改为在 2.0 中托管。它可能会解决一些问题，但您应该先尝试测试一下。
我们还使用了一个自制脚本来登录页面，并每隔 X 分钟检查一次可用性。当它没有响应时，我们会收到警报/电子邮件并在用户抱怨之前回收该过程。