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

71

我一直在搜索有关此信息无济于事。我为什么需要这个背景是我在这里问的另一个问题。更具体地说，在App_Data中创建/更新/删除文件是否会导致池回收？

如果有人可以提供导致回收的原因的详细列表，那将是很好的。

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

asp.net iis application-pool

— 斯拉沃
source

您确定它是池，而不仅仅是应用程序域？

— stephbu

泰斯（Tess）在AppDomain重置上的博客文章非常规范-她为ASP.NET团队工作。

— stephbu

31

两种不同的效果：

AppPool进程是潜在多个AppDomain的宿主。通常，可以通过多种效果将其回收。这些可能是时间（每n小时），缺乏请求，内存使用等；所有这些都在IIS Config Manager中配置。
AppDomain（应用程序根目录的托管实例）可以更频繁地循环，而不会影响AppPool中的其他AppDomain。苔丝（Tess）在AppDomain回收方面的文章颇有见地。

您正在写入受监视的文件夹以进行重新编译。这将在某个时候触发AppDomain重新创建。

事件日志将帮助您确定是什么原因引发了回收。

— 斯蒂布
source

1

请注意，在我的测试中，通过Web.config中带有configSource属性的部分引用的配置文件的更改也会导致应用程序域重启。

— 肖恩

是的，Shaun是很有可能的，这个答案是10年前写的，当时configSource只是一个积压的想法：-)此后，模式已发生了很大变化-欢迎编辑此答案以反映此后的进展。令我感到高兴的是，这个答案仍然有效，并且正在积极地进行交易。

— stephbu '18

39

您在另一篇文章中喜欢的文章实际上做得很好。

立即回收

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

延迟回收

可能发生在其他位置的多次更改，通常情况下，虽然我只注意到.aspx或.cs / .vb文件的更改。添加临时文本，csv或其他文件对我来说没有问题。

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

— 米切尔卖家
source

1

谢谢，米切尔。但这并没有特别说明App_Data。虽然这里说的是所有App_文件夹：weblogs.asp.net/owscott/archive/2006/02/21/ASP.NET-v2.0-2D00 -AppDomain -recycles_2C00_-more-common-than-before-aspx＃440333

— Slavo

我相信哪一个-正是这些不一致之处，因此我无法找到一个答案。

— Slavo

Slavo，这是事实，但是，我会谨慎对待文章的日期，因为我知道各种Service Pack都会在各个方面修改此行为。

— 米切尔卖家

我刚刚更改了App_Data文件夹中的文件，这导致了回收，但是，我应该注意，该文件位于我的开发服务器上。我很快就会发现它是否会影响生产。

— 丹·多永

更改文本文件（例如aspx文件等）将导致重新编译，并最终也会触发应用程序池的重新启动。在system.web下有一个compilation元素的属性，称为numRecompilesBeforeAppRestart。默认值为20。这意味着在20重新编译后，应用程序池将回收。

— Rob Sedgwick 2014年

27

您可能要打开完整的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目录的应用程序-文件更改过多导致回收...

— 克里斯托弗·刘易斯
source

1

仅供参考：adsutil.vbs应该已经存在于机器上。在我的机器上，它同时存在于c：\ Inetpub \ AdminScripts \和c：\ WINDOWS \ ServicePackFiles \ i386中。

— Jim G.

@Christopher_G_Lewis您可以详细说明您提到的问题，将日志文件写入wwwroot目录-文件更改过多会导致回收。

— Bhagirath N Sai 2015年

@ Bhagirath-N-Sai-如果FCN检测到某些更改，则IIS将回收应用程序池-请参阅导致应用程序池意外回收的常见原因

— Christopher G. Lewis

@Christopher_G_Lewis您能在stackoverflow.com/questions/27859599/…中

— Bhagirath N Sai

2

这可能每天都会根据首选项发生，或者在超出该进程的最大虚拟内存时发生。

— 本·谢尔曼
source

我了解这些原因。我是在问什么应用程序（与IIS不相关）更改将导致回收。

— Slavo

嗯好更改app_data文件夹不应回收，但您可以考虑在applicaiton_start发生时写入日志，以便确定。

— 本·谢尔曼

这就是我在这里收到一些回复后要做的事情：）

— Slavo

1

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

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

IIS重置也可以解决问题，停止/启动服务也可以。

— 米尔纳
source

0

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:

— 杰瑞德
source