IIS应用程序池回收似乎未遵守指定的日程安排
问题描述:
我们正在使用IIS中托管的远程应用程序跟踪连接泄漏,以清除在一天中的特定时间安排AppPool回收的孤立连接。 但是我没有看到证据表明这个回收是按照计划发生的 - 我已经更改了元数据库属性,因此IIS将记录所有回收,并记录手动回收命令。IIS应用程序池回收似乎未遵守指定的日程安排
什么可能会阻止IIS观察计划?
答
当您执行应用程序池回收(按计划)时,会启动新的工作进程(w3wp.exe
)。现有的工作进程保持活动状态以处理现有请求,然后在没有更多请求时关闭。所有新请求都发送到新的工作进程。
您可以检查您正在回收的应用程序池是否为新的w3wp.exe
进程。您可以通过以下IIS管理脚本做到这一点:
c:>iisapp.vbs
W3WP.exe PID: 5924 AppPoolId: MSSharePointAppPool
W3WP.exe PID: 2840 AppPoolId: Problem Sites - ASP.NET 2.0
W3WP.exe PID: 2576 AppPoolId: DefaultAppPool
W3WP.exe PID: 6076 AppPoolId: ASP.NET 2.0
W3WP.exe PID: 4916 AppPoolId: Problem Sites - ASP.NET 1.1
记下该进程的ID之前和计划的回收时间后,看看他们是否改变。
如果cscript不是您的默认WSH脚本宿主,则可能需要使用:cscript iisapp.vbs
。
当一个应用程序池回收,你也应该看到以下事件在您的系统事件日志:
Event Type: Warning
Event Source: W3SVC
Event Category: None
Event ID: 1013
Date: 22/06/2009
Time: 19:18:09
User: N/A
Computer: UK1SRD1602
Description:
A process serving application pool 'ASP.NET 2.0' exceeded time limits during
shut down. The process id was '2788'.
此事件将在Idle timout
(应用程序池属性指定的分钟数后出现 - >性能选项卡)加上现有工作进程完成任何挂起请求所需的时间长度,并且最后一个ASP.NET应用程序域被拆除(现有的ASP.NET会话将由旧的工作进程提供服务,直到没有更多的时间)。
你怎么知道应用程序池没有被回收?进程ID是否保持不变? – Kev 2009-06-23 15:49:27