2

我们正在跟踪使用托管在 IIS 中的远程处理的应用程序中的连接泄漏，以便清除孤立的连接，我们已在一天中的指定时间安排 AppPool 回收。但是，我没有看到证据表明这种回收是按照计划进行的——我已经更改了元数据库属性，因此 IIS 将记录所有回收并记录手动回收命令。

什么可能阻止 IIS 遵守计划？

4

1 回答 1

4

当您执行应用程序池回收（按计划）时，将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 iisapp.vbs如果 cscript 不是您的默认 WSH 脚本主机。

当应用程序池回收时，您还应该在系统事件日志中看到以下事件：

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 会话将由旧的工作进程提供服务，直到没有更多会话为止）。

于 2009-06-23T16:32:15.787 回答