什么导致IIS中的应用程序池重新启动？

Question

我一直在寻找相关信息，但并没有结果。我需要这个的背景是我在这里提出的另一个问题。更具体地说，是否在App_Data中创建/更新/删除文件会导致池重新启动？

如果有人能提供一个详细的列表，列出什么会导致池重新启动，那就太好了。

更新：正如两位用户已经注意到的那样，我也很乐意获得一个答案，指定仅重新启动AppDomain而不是整个池的原因。

- Slavo

---

你确定是池而不仅仅是应用程序域吗？ - stephbu

Tess关于AppDomain重置的博客文章非常经典 - 她是ASP.NET团队的成员。 - stephbu

Answer 1

你喜欢的那篇文章在另一篇帖子中做得非常好。

立即回收

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

延迟回收

可能会出现在其他位置进行多个更改，但通常情况下，我只注意到在 .aspx 或 .cs/.vb 文件更改时才出现问题。添加临时文本、csv 或其他文件并没有给我带来问题。

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

- Mitchel Sellers

---

谢谢，Mitchel。但它并没有特别说到 App_Data。而这里则是提到所有的 App_ 文件夹：http://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，这是真的，但是我会谨慎地考虑文章发布的日期，因为我知道各种服务包在不同时间点上修改了此行为。 - Mitchel Sellers

我刚刚更改了一个 App_Data 文件夹中的文件，导致应用程序池重启，但需要注意的是这是在我的开发服务器上。不久后我会查明它是否影响生产环境。 - Dan Doyon

更改像aspx文件等文本文件将导致重新编译并最终触发应用程序池的重启。在system.web下有一个编译元素的属性，称为numRecompilesBeforeAppRestart。默认值为20。这意味着在20次重新编译后，应用程序池将进行回收。 - Rob Sedgwick

Answer 2

两种不同的影响：

• AppPool进程是潜在多个AppDomains的主机。通常可以通过一些因素进行回收，例如时间（每隔n小时）、请求不足、内存使用等，都可在IIS Config Manager中配置。

• AppDomain是您应用程序根目录的托管实例，可以更频繁地循环使用，而不会影响AppPool中的其他AppDomains。Tess的关于AppDomain回收的帖子非常有启发性。

您正在写入一个目录，该目录受到重新编译监视。这将在某个时候触发AppDomain的重建。

事件日志将帮助您确定何种原因引起了回收。

- stephbu

---

请注意，在我的测试中，对 Web.config 中使用 configSource 属性引用的配置文件所做的更改也会导致应用程序域重新启动。 - Shaun

是的，Shaun，这是十年前写的答案，当时configSource只是一个待办事项中的想法 :-) 自那以后模式已经发生了很大变化 - 欢迎编辑此答案以反映此后的进展。我有点开心这个答案仍然有效并且活跃。 - stephbu

Answer 3

你可能希望打开完整的应用程序池回收事件日志：

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目录，导致文件变化过多而造成回收...

- Christopher_G_Lewis

---

请注意：adsutil.vbs 应该已经存在于计算机上。在我的计算机上，它存在于 c:\Inetpub\AdminScripts\ 和 c:\WINDOWS\ServicePackFiles\i386 两个目录下。 - Jim G.

@Christopher_G_Lewis，您能详细说明一下您提到的问题吗？将日志文件写入wwwroot目录会导致太多的文件更改，从而导致应用程序池回收。 - Bhagirath N Sai

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

@Christopher_G_Lewis 你能帮我解决http://stackoverflow.com/questions/27859599/erratic-behavior-of-preload中的问题吗？ - Bhagirath N Sai

Answer 4

这可能是根据偏好每天发生的，或者是当进程的最大虚拟内存超过时发生的。

- Ben Scheirman

---

我理解这些原因。我更想问的是，什么应用程序（与IIS无关）的更改会导致回收。 - Slavo

啊，好的。更改app_data文件夹不应该回收，但您可以考虑在应用程序启动时写入日志，以便您可以确定。 - Ben Scheirman

在这里得到几个回复后，那就是我要做的事情 :) - Slavo

Answer 5

这是一个设置，您可以根据应用程序池运行的时间或处理的请求数量来操作它进行回收。

它还会在 web.config 更改和其他已发布的内容上进行回收。

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

- Milner

Answer 6

w3wp.exe 出现错误。这导致在 Global.asax 中调用了 Application_Start。

为了找出原因，我打开了事件查看器。

在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: 

- Jesus is Lord