iis6.0应用程序池回收和工作进程(转)-我的大房子-博客园公司的一个网站程序长时间运行后，速度变慢，重新启动网站后速度明显变快，估计是网站程序占用的内存和CPU 资源没能及时释放，才需要每隔一段时间重启网站释放资源。

但手工重启总不能算解决问题的方法，怎样才能实现自动管理呢？IIS6.0的应用程序池自动回收功能可以解决这一问题。

问题如下：1.网页上显示您试图在此Web 服务器上访问的Web 应用程序当前不可用。

请点击Web 浏览器中的“刷新”按钮重试您的请求。

管理员注意事项:详述此特定请求失败原因的错误信息可在Web 服务器的系统事件日志中找到。

请检查此日志项以查明导致该错误发生的原因。

2.windows事件查看器-应用程序LogThe state server has closed an expired TCP/IP connection. The IP address of the client is 127.0.0.1. The expired Read operation began at 05/21/2007 20:12:04.解决的方法很简单，把程序对应的IIS应用程序池回收一下就好了。

可是为什么会出现这个原因呢？还有为什么回收一下就好了呢？回收做了些什么？出现的原因在网上搜索了一翻，发现主要是一下几个问题，当然还有其他原因1）.Framework的问题，例如1.0和2.0版本2）aspnet_wp.exe 问题3）安全更新程序(KB886903)可惜我们服务器出现的问题都不是以上几点引起的，经过我的分析认为是写的很烂很烂的程序占用了大量的资源最后导致内存泄漏，导致IIS的进程当掉了。

可惜了程序我是没办法改，都是别人写的，也不会改。

不过我不可能每次出现这个问题就登陆到远程服务器上去回收一次吧，所以只有让他自动回收了。

自动回收有好几种方式，也不知道那一种比较适合，而且回收工作进程是会把保存在内存里的Session清空，造成用户需要重新登陆的问题，所以自动回收要越少越好，以保证不会因为其中的一个用户使用了那个很烂的程式导致其他的用户都要重新登陆。

如果用了状态服务器或者是把Session保存到了数据库中去的程序自动回收后肯定是没有任何影响的，请求也不会中断还是一样继续运行，只是换了个工作进程继续为客户端工作，客户端是感觉不到的，当初没有为了方便没有把Session 保存到数据库真是失策！根据运行时间系统默认是1740分钟,也就是29个小时,这个不是很好控制,建议不用，也就是去掉那个勾。

请求数目这个要看具体的情况了。

如果只有10个请求，可是有5个都在请求那个比较占资源的页面（可能是统计年度报表之类），这个时候就会出现进程当掉的情况，如果请求有1000个可是一个也没运行比较占资源的页面，这个时候进程肯定是很正常的，所以根据请求的数目来决定也不符合实际需要。

计划的时间这个其实很好，不过具体什么时间回收好呢？通常我们都是设置上班前和下班后回收，这个时候回收是有必要的，不过针对出现随时可能出现是高内存占用并不是很适用。

内存（虚拟内存或已使用的内存）这个针对出现内存问题引起的进程当掉实在太合适了，不过设置多大的值比较好是一个很重要的问题，我是根据每次出现问题时进程是实际占用情况决定的。

我们的服务器内存是2G，通常其他的一些服务会占用掉600多M，我发现有每次进程都是到1G多的时候当掉，所以设置了最大使用内存为1000M的时候自动回收，设置后一直都没出现问题了。

要查看进程的占用直接用windows任务管理器就好，值不能太小了，否则如果访问量都很大超过这个值的时候也会自动回收，这个就很没必要了。

一定要多多观察进程的实际占用情况再做决定。

在IIS的配置文件里面如果配置了IIsApplicationPools节点的LogEventOnRecycle属性，每次回收的时候IIS的日志文件会根据LogEventOnRecycle属性的值纪录下相关的信息，也个也是设置自动回收时的一个重要参考，不过由于这个日志文件只能看几个小时以前的纪录，当前的纪录要几个小时后才写进去，所以看起来不方便，郁闷！现在暂时根据最大占用内存自动收回以前的问题是解决了，暂时也发现什么新问题了，也不知道其他地方都是怎么设置的，是不是还有更好的方法呢？希望到了这篇文章的人能提点宝贵意见，大家一起交流一下经验。

IIS的配置文件在windows的安装目录下（C:\WINDOWS\system32\inetsrv\MetaBase.xml），直接修改配置文件需要停止IIS服务，修改前记得备份。

部分配置信息，写的好玩的<IIsApplicationPool Location="/LM/W3SVC/AppPools/DefaultAppPool"AppPoolAutoStart="TRUE"PeriodicRestartMemory="2000" //最大虚拟内存MBPeriodicRestartPrivateMemory="1000" //最大占用内存MBPeriodicRestartRequests="1000" //请求数PeriodicRestartSchedule="07:50 //自动回收时间12:0020:00"></IIsApplicationPool>以下是摘录IIS自带的帮助。

工作进程回收如何工作根据应用程序池回收的配置方式，万维网发布服务（WWW 服务）可以使用两种方法来回收已分配的工作进程：默认情况下，WWW 服务建立“重叠回收”，即继续运行要终止的工作进程，直到启动新的工作进程后为止。

或者，WWW 服务可以终止一个工作进程，然后启动一个新的工作进程（如果工作负荷允许执行此操作的话）。

注意当WWW 服务回收某个工作进程时，它并不断开现有的TCP/IP 连接。

HTTP 协议堆栈(HTTP.sys) 建立并维护TCP/IP 连接。

在重叠回收方案中，要回收的进程继续处理请求，同时WWW 服务创建一个替代工作进程。

在停止旧工作进程之前启动新的工作进程，然后将请求定向到新的进程。

此设计可以防止服务中断，因为旧进程关闭前仍然保持与HTTP.sys 的通信以处理请求。

因为可重叠关闭或启动的关闭超时值是可以配置的，所以在工作进程仍在处理请求的同时可以终止该进程（如果它在时间限制内没有处理完请求的话）。

在配置应用程序池以基于运行时间来回收工作进程时，可以在设置的运行时间内回收所有的工作进程，但不能同时回收所有这些工作进程。

可以在设置的时间内的不同时段进行回收应用程序，以减少客户端请求服务的中断次数。

类似地，在配置应用程序池以基于处理请求的数目来回收应用程序时，可以每隔一段时间回收一次以分担与工作进程回收有关的系统开销。

何时使用工作进程回收在决定是否启动工作进程回收时，应考虑以下常规指南。

最佳的解决方案是修复引起故障的应用程序。

但是，并非总能使用重新编码，尤其是运行的其他应用程序代码无法修改时。

在以下情况下考虑使用回收：无法修复Web 服务器上您所主控的有故障的应用程序。

遇到不能确定的或间断性的故障。

您怀疑应用程序由于性能监视的原因而泄漏内存。

先前已实施了临时性的重置解决方案，例如，计划执行IISReset 命令行实用工具。

在以下情况下，可能根本不需要使用回收：您所主控的网站只包含静态内容，并且不包含自定义Internet 服务器API (ISAPI) 应用程序。

您所主控的应用程序已经过完全测试，并且不会出现内存或资源分配问题。

要有效地使用回收，请仔细检查回收所依据的标准（如下表中所示）。

回收依据的条件描述使用时间ISAPI 请求根据应用程序池中ISAPI 的请求回收工作进程。

ISAPI 扩展可以将其自身声明为运行状况差。

运行时间根据用户指定的时间（分钟）回收工作进程。

存在故障的应用程序的运行时间过长。

请求数目当超文本传输协议(HTTP) 请求超出某个特定阈值时回收工作进程。

根据应用程序接收到的请求数目，应用程序出现故障。

计划的时间在24 小时内的指定时间进行回收。

条件与运行时间的条件类似。

虚拟内存（保留的内存加上已使用的内存）当工作进程虚拟内存达到某个特定阈值时回收该工作进程。

内存堆栈碎片过多（这是由于应用程序保留多次内存造成的）。

症状是虚拟内存持续增加。

已使用的内存当W3wp.exe 进程使用的内存达到某个特定阈值时回收工作进程。

某些应用程序出现内存泄漏。

根据需要当IIS 管理员可以使用Microsoft® 管理控制台(MMC) 或脚本控制整个应用程序池的回收时开始回收。

在其他站点启动并运行时，有一个引起故障的应用程序池。

请考虑回收该应用程序，而无需重置整个WWW 服务。

应用程序池是将一个或多个应用程序链接到一个或多个工作进程集合的配置。

因为应用程序池中的应用程序与其他应用程序被工作进程边界分隔，所以某个应用程序池中的应用程序不会受到其他应用程序池中应用程序所产生的问题的影响。

为Web程序配置应用程序池需要以下步骤：1）创建应用程序池，右键单击“应用程序池”，“新建/应用程序池”，命名为KefuAppPool；2）为Web程序指定应用程序池，在网站虚拟目录属性“应用程序设置”里面的“应用程序池(N)”里选择KefuAppPool；3）应用程序池自动回收方式的设置。

回收方式有如下几种：a.根据运行时间系统默认是1740分钟,也就是29个小时,这个不是很好控制,建议不用。

在命令提示符下运行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）正式替代旧进程工作，这就很好的防止了应用程序池回收过程中服务被中断，保证了程序的连续运行。