Question

我一直在寻找这方面的信息无济于事。我需要这个的背景是another question I asked here。更具体地说，在App_Data中创建/更新/删除文件会导致池回收吗？

如果有人能提供导致回收的详细清单，那就太棒了。

更新：正如两位用户已经注意到的那样，我也很乐意回答指出仅回收AppDomain而不是整个池的原因。

Answer 1

你喜欢的另一篇文章实际上做得非常好。

立即回收

Web.config更改
Machine.config更改
Global.asax更改
Bin目录更改
App_Code更改

延迟回收

在其他位置发生多次更改时可能会发生这种情况，通常情况下，我只会注意到.aspx或.cs / .vb文件的更改。添加临时文本，csv或其他文件并没有给我带来任何问题。

注意：这些都是应用程序域回收，而不是池的实际回收。通常，应用程序POOL将仅基于IIS中的设置（请求数，内存限制，空闲时间或计划重新启动）进行回收。

Answer 2

两种不同的效果 - AppPool进程是潜在多个appdomains的主机。通常，这可以通过许多效果再循环，例如，时间 - 每隔'n'小时，缺少请求，内存使用等。在IIS配置管理器中配置。

AppDomain - 应用程序根目录的托管实例，可以更频繁地循环，而不会影响AppPool中的其他AppDomain。 Tess在AppDomain回收上的帖子非常有见地

http://blogs.msdn.com/tess/archive/2006/08/02/asp-net-case-study-lost-session-variables-and-appdomain-recycles.aspx

您正在写入受重新编译监控的文件夹 - 这将在某个时刻触发appdomain娱乐。

事件日志将帮助您确定启动回收的原因。

Answer 3

您可能想要打开完整的AppPool回收事件日志：

cscript adsutil.vbs Set w3svc/AppPools/DefaultAppPool/LogEventOnRecycle 255

您还可以查看Scott Guthrie的博客文章：http://weblogs.asp.net/scottgu/archive/2005/12/14/433194.aspx，该文章介绍如何在Global.ASAX中编写代码以记录Application.End事件的实际原因。

这对我们诊断几个棘手的问题非常有用 - 一个特别是一个将日志文件写入wwwroot目录的应用程序 - 太多文件更改导致回收......

Answer 4

这可以根据偏好每天发生，也可以在超出过程的最大虚拟内存时发生。

Answer 5

这是一个设置，您可以根据其运行的分钟数或已处理的请求数来操作以回收应用程序池。

它还将回收web.config更改以及此处发布的其他内容。

IIS重置也会起作用，停止/启动服务也是如此。

Answer 6

w3wp.exe出了错。这导致Application_Start中的Global.asax被调用。

要找到答案，我打开了事件查看器。

在 Windows日志下，我转到了应用程序。

我看到了应用程序错误：

Faulting application name: w3wp.exe, version: 10.0.16299.15, time stamp: 0x0aeb5595
Faulting module name: KERNELBASE.dll, version: 10.0.16299.334, time stamp: 0x6369e29f
Exception code: 0xe0434352
Fault offset: 0x0000000000014008
Faulting process id: 0x2900
Faulting application start time: 0x01d43b16f726cbb9
Faulting application path: c:\windows\system32\inetsrv\w3wp.exe
Faulting module path: C:\WINDOWS\System32\KERNELBASE.dll
Report Id: 998cf55d-2cd9-4b8d-9884-2110e3fd1411
Faulting package full name: 
Faulting package-relative application ID:

是什么原因导致IIS中的应用程序池回收？

6 个答案: