我一直在搜索这方面的信息,但无济于事。我为什么需要这个的背景是我在这里问的另一个问题。更具体地说,在 App_Data 中创建/更新/删除文件会导致池回收吗?
如果有人可以提供导致回收的原因的详细列表,那就太好了。
更新:正如两个用户已经注意到的那样,我也很乐意回答指定仅回收 AppDomain 而不是整个池的原因。
我一直在搜索这方面的信息,但无济于事。我为什么需要这个的背景是我在这里问的另一个问题。更具体地说,在 App_Data 中创建/更新/删除文件会导致池回收吗?
如果有人可以提供导致回收的原因的详细列表,那就太好了。
更新:正如两个用户已经注意到的那样,我也很乐意回答指定仅回收 AppDomain 而不是整个池的原因。
您在另一篇文章中喜欢的文章实际上在这方面做得非常好。
立即回收
延迟回收
可能会在其他位置发生多次更改,但通常我只注意到对 .aspx 或 .cs/.vb 文件的更改。添加临时文本、csv 或其他文件并没有给我带来问题。
注意:这些都是应用程序域回收,而不是池的实际回收。通常,应用程序池将仅根据 IIS 中的设置(请求数、内存限制、空闲时间或计划重启)进行回收。
两种不同的效果:
AppPool 进程是潜在的多个 AppDomain 的宿主。通常,这可以通过许多效果来回收。这些可能是时间(每n小时)、请求不足、内存使用等;所有在 IIS 配置管理器中配置。
AppDomain(应用程序根的托管实例)可以更频繁地循环,而不会影响 AppPool 中的其他 AppDomain。Tess 关于 AppDomain 回收的帖子非常有见地。
您正在写入受监视以进行重新编译的文件夹。这将在某个时候触发 AppDomain 重新创建。
事件日志将帮助您确定启动回收的原因。
您可能想要打开完整的 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 目录的应用程序 - 太多的文件更改导致回收......
这可以根据偏好每天发生,或者在超过进程的最大虚拟内存时发生。
这是一个设置,您可以根据应用程序运行的分钟数或已处理的请求数对其进行操作以回收应用程序池。
它还将回收 web.config 更改和已在此处发布的其他内容。
IIS 重置也可以解决问题,停止/启动服务也是如此。
w3wp.exe
出错了。这导致Application_Start
被调用Global.asax
。
为了找出答案,我打开了Event Viewer。
在Windows Logs下,我去了Application。
我看到一个应用程序错误:
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: