什么导致IIS中的应用程序池回收？
我一直在寻找这方面的信息无济于事。 为什么我需要这个背景是我在这里问的另一个问题 。 更具体地说，在App_Data中创build/更新/删除文件会导致池回收？
如果有人可以提供一个回收的详细清单，这将是很好的。
更新 ：作为两个用户已经注意到，我也很乐意回答指定回收AppDomain的唯一原因，而不是整个池。
两种不同的效果 – AppPool进程是潜在的多个AppDomain的主机。 通常情况下，这可以通过一些影响，例如时间 – 每“n”小时，缺less请求，内存使用等回收。在IISconfigurationpipe理器中进行configuration。
AppDomain – 应用程序根的托pipe实例可以更频繁地循环，而不会影响AppPool中的其他AppDomain。 Tess在AppDomain回收上的post非常有见地
您正在写入一个监视重新编译的文件夹 – 这将触发appdomain娱乐在某个时刻。
事件日志将帮助您确定启动回收的原因。
在另一篇文章中你喜欢的文章实际上做了很好的工作。
立即回收
- Web.config更改
- Machine.config更改
- Global.asax更改
- Bin目录更改
- App_Code更改
延迟回收
可以发生在其他位置的多个更改，通常，我只注意到与.aspx或.cs / .vb文件的更改。 添加临时文本，CSV或其他文件没有给我带来问题。
注意：这些都是应用程序域回收，而不是实际回收池。 通常，应用程序POOL将仅基于IIS中的设置（请求数，内存限制，空闲时间或计划重新启动）进行回收。
您可能想打开完整的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中编写代码来loggingApplication.End事件的实际原因。
这对于我们诊断一些棘手的问题非常有用 – 特别是一个应用程序正在将日志文件写入wwwroot目录 – 太多的文件更改导致回收…
这可能会根据偏好每天发生，或者超过了过程的最大虚拟内存。
这是您可以根据运行的分钟数或处理的请求数来回收应用程序池的设置。
它也将回收web.config的变化和其他东西在这里发布。
IIS重置也可以做到这一点，就像停止/启动服务一样。
