.NET 应用程序失败 - 通过回收应用程序池解决
我正在查看一个 .NET ASP 应用程序（从支持方面来看 - 我没有对其进行编程）。
它间歇性挂起 - 网页无法打开。 回收应用程序池可以修复它。
我可以在事件查看器中看到条目说明
进程服务器应用程序池“wsfrappPool”在关闭期间超出了时间限制。 进程 ID 是来自 W3SVC 的“9396”。
我也能看到
为应用程序池“AeXRSVaultPool”提供服务的进程 ID 为“6804”的工作进程已请求回收，因为该工作进程已达到允许的处理时间限制。
我正在寻求有关如何找出导致挂起的原因并防止其再次发生的建议。 我可以使用性能计数器来跟踪这一点吗？ 这些事件查看器条目相关吗？
I am looking at a .NET ASP application (from the support side - I didn't program it).
It intermittently hangs - the web page doesn't open. Recycling the app pool fixes it.
I can see entries in the event viewer stating
A process server application pool 'wsfrappPool' exceeded time limits during shut down. The process id was '9396' from W3SVC.
I can also see
A worker process with process id of '6804' serving application pool 'AeXRSVaultPool' has requested a recycle because the worker process reached its allowed processing time limit.
I'm looking for advice on how I can track down what is causing the hang and prevent it re-occurring. Can I use performance counters to track this? Are those event viewer entries relevant?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
检查 IIS 日志，了解应用程序崩溃之前的最后几个请求。 这可能会提示您哪些页面可能导致问题。
我在使用 .net 1.* 时遇到了很多类似的问题，这主要是由于内存不足或工作进程内存膨胀到超过 1GB 造成的。 （有很多大文件上传，一些显式的 GC.Collect() 调用有所帮助 - 一个不好的，但需要修复）自 2.0 以来，我没有遇到过这种问题（大文件和所有，没有 GC.Collects） 。
事件查看器事件可能描述了您回收池的操作。
Check the IIS logs to see what the last few requests were before the app went belly up. That may clue you in to what page(s) may be causing the problem.
I had lots of problems like this with .net 1.*, and it was mostly due to out of memory conditions or when the worker process balooned to over 1GB of memory. (There was a lot of large file uploading, a few explicit GC.Collect() calls helped - a bad, but needed fix) Since 2.0, I havent had this kind of problem (large files and all, without the GC.Collects).
The event viewer events are likely describing your action of recycling the pool.