[置顶] 应用程序池提供服务的进程关闭时间超过了

 " 为应用程序池 'AppPool #1' 提供服务的进程关闭时间超过了限制" 的错误出现究其原因是由于网站的访问量连接数过大，引起应用程序池处理连接的时候，新的还没有接替，而旧的又要回收，但在回收的过程中不及时，照常应用程序池当机，网站无法访问，出现了这个错误。

   当网站无法访问的时候，手动回收应用程序池，即可恢复，不过手动恢复的话，毕竟很麻烦，你不能一天都盯着这个网站看吧？问题出在应用程序池的话，那我们就从应用程序池的配置下手来看是否能解决问题。

1、首先建议每个网站分别建立一个应用程序池，一个应用程序池将对应不同的w3wp.exe进程，在“命令提示符”下使用iisapp命令 可以察看网站对应的w3wp.exe的pid值，方便查找出问题的进程。

   2、应用程序池的配置
      个人意见觉得在应用程序池的属性窗口中，“回收”和“运行状况”2个选项卡的配置比较重要。

2.1、回收 选项卡

    1、回收工作进程（分钟）：在工作进程运行多少分钟后回收工作进程，默认启用，并且设置为1740分钟（29小时）；
           2、回收工作进程（请求数目）：在工作进程处理多少 个HTTP请求后终止此工作进程，默认禁用，如果启用则默认值为35000；
           3、在下列时间回收工作进程：在指定的时间回收工作进程，默认禁用；如需启用，勾选后点击添加按钮添加回收的时间即可，使用24小时制定义回收的时间；
          4、消耗太多内存时回收工作进程：
               最大虚拟内存（兆）：当工作进程使用的虚拟内存达到设置的值时回收工作进程，默认禁用，如果启用则默认值为500 M；建议设置为不超过虚拟内存总数的70％；
               最大使用的内存（兆）：当工作进程使用的物理内存达到设置的值时回收工作进程，默认禁用，如果启用则默认值为192 M；建议设置为不超过物理内存总数的60％；

2.2、性能

      1、在空闲此段时间后关闭工作进程（分钟）：当工作进程空闲多少分钟后关闭此工作进程，这降低了空闲工作进程对系统资源和CPU性能的消耗，默认启用并且设置为20分钟； 

      2、核心请求队列限制为（请求次数）：当HTTP.sys接收到某个客户端发送的HTTP请求时，如果处理此请求的对应应用程序池的工作进程还处于忙状态，则HTTP.sys将接收到的请求保存在对应应用程序池的请求队列中，直到工作进程空闲为止。此选项即用于设置此应用程序池的请求队列所能容纳的请求数量，默认情况下每个应用程序池的请求队列限制为保留1000个请求，如果超出则向客户端返回503错误，你可以根据需要适当进行修改，最大可以设置为65535。但是如果设置太大则会消耗大量的系统资源 ，而设置太小会导致客户端访问时频繁出现503错误。

         

2.3、运行状况

1、启用Ping：默认情况下应用程序池配置为每隔30秒Ping工作进程，当工作进程没有进行响应时，则认为此工作进程出现故障并默认配置为关闭此工作进程。你可以修改Ping的时间间隔，但是太长的Ping间隔可能会导致Web服务的中断，而太短的Ping间隔又会消耗更多的系统资源和CPU利用率，因此建议你保留默认配置；
        2、启用快速失败保护：如果Web应用程序代码编写有问题，它可能会导致工作进程持续出现问题。默认情况下应用程序池配置为启用快速失败保护，当工作进程在配置的时间段（默认为5分钟）内发生的失败次数超过了配置的值（默认为5次），则禁用此应用程序池。
        3、启动时间限制：IIS等待属于此应用程序池的工作进程启动的时间，当工作进程启用时间超出此设置值时，IIS会在事件日志中进行记录；
        4、关闭时间限制：当IIS检测到某个工作进程出现故障时，将此工作进程标记为关闭，此选项指定了IIS等待工作进程自动关闭的时间限制，如果超出此时间限制后工作进程尚未关闭，则IIS强行关闭工作进程。

不同的情况下有不同的设置方法，

[引用:iis 回收工作进程时出错的解决办法

第一种解决方案：

iis6系统默认的工作进程回收时间是29个小时有很多问题是在回收工作进程后出现很多问题如典型的500错误等经过我做服务器的一段时间的观察大家可以不用回收工作进程而是把应用程序池的最大使用内存调整到一个合适的值就可以了，因为如果设置了不回收工作进程，哪么这个应用程序池所占用内存的体积会很大并在不短增加中，我们设置了这个池最大使用内存的大小就控制注了这个应用程序池的程序变化在一个合理的值里

 

第二种解决方法：

IIS6的应用程序池会经常出现一些问题

[查看系统日志会发现下边错误]

为应用程序池 'DefaultAppPool' 提供服务的进程关闭时间超过了限制。进程 ID 是 '3484'。

[随之而来的还有]

事件 ID ( 54 )的描述(在资源( HTTP )中)无法找到。本地计算机可能没有必要的注册信息或消息 DLL 文件来从远程计算机显示消息。您可能可以使用 /AUXSOURCE= 标识来检索词描述；查看帮助和支持以了解详细信息。下列信息是事件的一部分: /Device/Http/AppPool.

网上查了很多资料，多说是应用程序池无法在指定的时间内回收造成的。适当的延长时间即可解决，最开始我设定为10分钟内必须回收。但是问题依旧。无奈只好关闭了回收，不回收的结果就是内存得不到释放，一次手动回收程序池并观察进程动态，让我突然明白其中道理。

每个程序池都会有个独立进程 w3wp.exe ，而在回收程序池时，系统会新建个w3wp.exe进程，用于处理新的web请求，从而慢慢释放旧的进程。如果在指定时间内旧的进程没有释放完，那么就会导致程序池出错。

所以，把时间设长点就行了，我设成了3600秒，也就是一小时。设定之后程序池就再没出现过问题，每天观察服务器，内存都能被很好的释放。

下面是我的程序池设定，仅供参考。

右击应用程序池DefaultAppPool，选取属性：

一、回收

1、回收工作进程（分钟）：（不选）

2、回收工作进程（请求数目）：（不选）

3、在下列时间回收工作进程：我设定为凌晨3点，因为那个时候访问量最少，请求最少，较容易释放资源。

4、消耗太多内存时回收工作进程：（不选）

二、性能

   空闲超时20分钟：（不选）

   请求队列限制：（不选）

   WEB园最大工作进程数为1（默认）。

三、运行状况

   启用ping：选中

   启用快速失败保护：不选。

   启动时间限制：900秒

   关闭时间限制：3600秒。

 

第三种解决方法：

因为应用程序池 DefaultAppPool 提供服务的进程关闭时间超过了限制 服务器经常产生“应用程序池 DefaultAppPool 提供服务的进程关闭时间超过了限制。进程 ID 是 2068。”的错误，导致iis处于假死状态，经了解是IIS应用程序池的设置问题。解决方法如下：Internet 信息服务(IIS)管理器－＞应用程序池－＞DefaultAppPool－＞右击属性一、回收1、回收工作进程（分钟）：选中，值为17402、回收工作进程（请求数目）：不选（原先设置为35000）3、在下列时间回收工作进程：不填4、消耗太多内存时回收工作进程：全不选。（2、3、4项可能避免了在访问量高的时候强制回收进程可能引发的服务器响应问题，导致iis假死不响应）二、性能只选中空闲超时20分钟。其他都不选。WEB园最大工作进程数为1（默认）。注意web园这里一定要保持默认，如果填写其他超过1的数字就会导致一些网站程序的后台程序打不开或者刷新不停。原来的请求队列限制为4000，现在无限制。三、运行状况前两项都起用，是原来的默认设置。启动时间限制90秒，关闭时间限制180秒。启动快速失败保护的钩去掉！为了避免真的遇到很多错误时没有提示，可以不关闭，只是把快速保护的保护范围加大些，例如失败数50次 时间段5分钟 则关闭对应的程序。“关闭时间限制180秒”是必须的，因为进程关闭的时间，原来为90秒限制,是默认值，如果进程关闭时间超过90秒，则认为超时，从而出现：进程关闭时间超过了限制 日志，所以，适当延长这个时间，可以避免这种错误

]

这篇博文里给出的方法不失为一些很好的解决方案，但是对于我的服务器而言，不能解决问题，我的网站由于有一个投票系统，有人刷票，这种刷票行为是不定时不确定的，来的时候大量访问，造成当机，不刷的时候服务器没什么流量，所以它所提到的方法不是很适合我的服务器。