iis应用程序池出错解决方法

2011-05-20 23:46 108 人阅读 评论(0) 收藏 举报 “ 为应用程序池 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 秒限制, 是默认值，如果进程关闭时间超过