IIS 6.0 w3wp.exe 应用程序池工作进程回收机制分析
公司一台服务器网站程序长时间运行后，速度变慢，重新启动网站后速度明显变快，估计是网站程序占用的内存和CPU资源没能及时释放，才需要每隔一段时间重启网站释放资源。但手工重启总不能算解决问题的方法，怎样才能实现自动管理呢？IIS6.0的应用程序池自动回收功能可以解决这一问题。
应用程序池是将一个或多个应用程序链接到一个或多个工作进程集合的配置。因为应用程序池中的应用程序与其他应用程序被工作进程边界分隔，所以某个应用程序池中的应用程序不会受到其他应用程序池中应用程序所产生的问题的影响。
为Web程序配置应用程序池需要以下步骤：
1）创建应用程序池，右键单击“应用程序池”，“新建/应用程序池”，命名为KefuAppPool；
2）为Web程序指定应用程序池，在网站虚拟目录属性“应用程序设置”里面的“应用程序池(N)”里选择KefuAppPool；
3）应用程序池自动回收方式的设置。回收方式有如下几种：
a.根据运行时间
系统默认是1740分钟,也就是29个小时,这个不是很好控制,建议不用。
b.请求数目
这个要看具体的情况了。如果只有10个请求，可是有5个都在请求那个比较占资源的页面（可能是统计年度报表之类），这个时候就会出现进程当掉的情况，如果请求有1000个可是一个也没运行比较占资源的页面，这个时候进程肯定是很正常的，所以根据请求的数目来决定也不一定符合实际需要。
c.计划的时间
这个其实很好，不过具体什么时间回收好呢？通常我们都是设置在凌晨两三点钟，这个时候回收是有必要的，不过针对出现随时可能出现是高内存占用并不是很适用。
d.内存（虚拟内存或已使用的内存）
这个针对出现内存问题引起的进程当掉实在太合适了，不过设置多大的值比较好是一个很重要的问题，值不能太小了，否则如果访问量都很大超过这个值的时候也会自动回收，这个就很没必要了。一定要多多观察进程的实际占用情况再做决定。
下面重点谈谈对工作进程回收应用程序池的理解。
默认情况下，WWW服务建立“重叠回收”，即继续运行要终止的工作进程，直到启动新的工作进程后为止。 在重叠回收方案中，要回收的进程继续处理请求，同时 WWW 服务创建一个替代工作进程。在停止旧工作进程之前启动新的工作进程，然后将请求定向到新的进程。此设计可以防止服务中断，因为旧进程关闭前仍然保持与 HTTP.sys 的通信以处理请求。因为可重叠关闭或启动的关闭超时值是可以配置的，所以在工作进程仍在处理请求的同时可以终止该进程（如果它在时间限制内没有处理完请求的话）。
注意：当 WWW 服务回收某个工作进程时，它并不断开现有的 TCP/IP 连接。HTTP 协议堆栈 (HTTP.sys) 建立并维护 TCP/IP 连接。
IIS中的每个应用程序池由一个“工作进程”进行管理，也就是"W3wp.exe" 进程。如果有多个应用程序池中的程序运行，我们就能看到多个w3wp.exe。这点可以在任务管理器中看到，如下图所示，任务管理器中有两个w3wp.exe进程，恰好对应两个有应用程序在运行的应用程序池。
在命令提示符下运行iisapp -a，可以查看w3wp.exe和哪个应用程序池关联。
1）在任务管理器中增加显示pid字段；
2）在命令提示符下运行iisapp -a。
注意，第一次运行，会提示没有js支持，点击确定。然后再次运行就可以了。这样就可以看到pid对应的应用程序池。如上图左侧所示，应用程序池KefuAppPool和PID=3232的w3wp.exe相关联，应用程序池ReportServer和PID=3572的w3wp.exe相关联。
下图显示了手动执行应用程序池KefuAppPool的回收，在回收前，回收中和回收后应用程序池和工作进程情况。我们注意到：回收过程中增加了一个工作进程（PID=3896），该工作进程（PID=3896）启动好后，旧的工作进程（PID=5716）才被停止，新工作进程（PID=3896）正式替代旧进程工作，这就很好的防止了应用程序池回收过程中服务被中断，保证了程序的连续运行。而其他两个应用程序池对应的工作进程PID都没用变。该图很好的展示了应用程序池回收的过程。
补充资料：
1、IIS应用程序池自动回收机制给我们带来便利的同时，也会造成潜在的问题。编写依赖于Global文件中全局事件的函数时我们要特别注意了，尤其是每天定时执行的函数，因为重新启动IIS应用程序池后，如果没有用户访问网站，则无法激活Application_Start事件，函数也就无法执行了。
2、IIS 应用程序池工作进程回收后经常会出现一些错误：
1）500错误或事件 ID ( 54 )的描述(在资源( HTTP )中)无法找到。本地计算机可能没有必要的注册信息或消息 DLL 文件来从远程计算机显示消息。您可能可以使用 /AUXSOURCE= 标识来检索词描述；查看帮助和支持以了解详细信息。
2）为应用程序池 'DefaultAppPool' 提供服务的进程关闭时间超过了限制。进程 ID 是 '3484'
3）应用程序池 DefaultAppPool 提供服务的进程关闭时间超过了限制 服务器经常产生“应用程序池 DefaultAppPool 提供服务的进程关闭时间超过了限制。进程 ID 是 2068。”的错误，导致iis处于假死状态
…………
一般有三种推荐解决方法或方式：
1）可以设置不回收工作进程而是把应用程序池的最大使用内存调整到一个合适的值，因为如果设置不回收工作进程，那么这个应用程序池所占用内存的体积会很大并在不短增加中，我们设置了这个池最大使用内存的大小就控制注了这个应用程序池的程序变化在一个合理的值里；
2）由上文可知：每个程序池都会有个独立进程 w3wp.exe ，而在回收程序池时，系统会新建一个w3wp.exe进程，用于处理新的web请求，从而慢慢释放掉旧的进程。如果在指定时间内旧的进程没有释放完，那么就会导致程序池出错。所以，可以把时间设长点，如3600秒，也就是一小时。设定之后再观察应用程序池是否还会出现问题，内存是否都能被很好的释放。例如设置：
右击应用程序池DefaultAppPool，选取属性：
A、回收
①、回收工作进程（分钟）：（不选）
②、回收工作进程（请求数目）：（不选）
③、在下列时间回收工作进程：我设定为凌晨3点，因为那个时候访问量最少，请求最少，较容易释放资源。
④、消耗太多内存时回收工作进程：（不选）
B、性能
①、空闲超时20分钟：（不选）
②、请求队列限制：（不选）
③、WEB园最大工作进程数为1（默认）。
C、运行状况
①、启用ping：选中
②、启用快速失败保护：不选。
③、启动时间限制：900秒
④、关闭时间限制：3600秒。
3）Internet 信息服务(IIS)管理器－＞应用程序池－＞DefaultAppPool－＞右击属性
A、回收
①、回收工作进程（分钟）：选中，值为1740
②、回收工作进程（请求数目）：不选（原先设置为35000）
③、在下列时间回收工作进程：不填
④、消耗太多内存时回收工作进程：全不选。
（②、③、④项可能避免了在访问量高的时候强制回收进程可能引发的服务器响应问题，导致iis假死不响应）
B、性能只选中空闲超时20分钟。其他都不选。WEB园最大工作进程数为1（默认）。注意web园这里一定要保持默认，如果填写其他超过1的数字就会导致一些网站程序的后台程序打不开或者刷新不停。原来的请求队列限制为4000，现在无限制。
C、运行状况前两项都起用，是原来的默认设置。启动时间限制90秒，关闭时间限制180秒。启动快速失败保护的钩去掉！为了避免真的遇到很多错误时没有提示，可以不关闭，只是把快速保护的保护范围加大些，例如失败数50次 时间段5分钟 则关闭对应的程序。“关闭时间限制180秒”是必须的，因为进程关闭的时间，原来为90秒限制,是默认值，如果进程关闭时间超过90秒，则认为超时，从而出现：进程关闭时间超过了限制 日志，所以，适当延长这个时间，可以避免这种错误。
此处评论已关闭