IIS的应用程序池 'DefaultAppPool'导致IIS假死机（转载）

线上环境有几台Window的机器，安装的是IIS服务，经常出现故障，对Window已无话可说了。今天又出现了一个错误，如图事件管理器记录的信息：

网络查找了相关资料，原因是IIS回收了pool资源，导致假死的现象，记录下，方便日后维护。

有一位博友提到了一个解决方法，暂时不知道是否可用，有待继续跟踪。

文章URL地址：
问题描述：最近发现，服务器的Web Server总是离奇的死机。查看Log：为应用程序池 'XXXXXXX' 提供服务的进程关闭时间超过了限制。进程 ID 是 '××××'。为应用程序池 'XXXXXXX'提供服务的进程 ID 为 ×××× 的 worker 进程已经请求回收，因为 worker 进程达到了允许的运行时间限制。

事件类型: 警告
事件来源: W3SVC
事件种类: 无
事件 ID: 6880
日期: 2012-05-09
16:01:51
用户: N/A
计算机:xxxxxx
描述:
为应用程序池 'XXXXXXX'提供服务的进程关闭时间超过了限制。进程 ID 是 '6884'。
有关更多信息，请参阅在 的帮助和支持中心。

分析原因：发 现这个问题出现的时间刚好是多人在线的情况下发生。用任务管理器观察了一下：发现web service（即W3SVC） 的进程有问题，内存页面错误的值很高。 ms给出的定义： Page Faults/sec 是指处理器中“页面错误”的数量。当一个进程引用不在主存储器“工作集”中的虚拟内存页时，就会发生页面错误。如果该页面在 Standby 列表上，因而已在主存储器中，或者如果另一个与其共享该页面的进程正在使用该页，那么发生“页面错误”时，不会从磁盘读取该页面。

解决方法：目前IIS服务器应用程序池设置如下：
右击应用程序池 'XXXXXXX'，如果使用的是'DefaultAppPool'就使用右击'DefaultAppPool'，选取属性：
一、回收
1、回收工作进程（分钟）：选中，值为1740
2、回收工作进程（请求数目）：不选（原先设置为35000）
3、在下列时间回收工作进程：不填
由于设定了进程自动回收，而当每达到10000次点击，或CPU超过100%,就会强行回收application，导致客户端会出现Sevice Unavailable的错误。(实际上10000次点击，访问量一般的网站，几分钟就够了。)
4、消耗太多内存时回收工作进程：全不选。（2、3、4项可能避免了在访问量高的时候强制回收进程可能引发的服务器响应问题）服务器内存够大，豁出去了给它用。
二、性能
只选中空闲超时20分钟。其他都不选。WEB园最大工作进程数为1（默认）。
原来的请求队列限制为4000，现在无限制。
三、运行状况
前两项都起用，是原来的默认设置。启动时间限制90秒，关闭时间限制180秒。
"关闭时间限制180秒"是必须的，因为进程关闭的时间，就是在这儿设置，原来为90秒限制,是默认值，如果进程关闭时间超过90秒，则认为超时，从而出现：进程关闭时间超过了限制日志，所以，适当延长这个时间，可以避免这种错误！
将每个应用程序设置不同的"应用程序池"。
然后服务器过10天或者20天回收一下应用程序池。另外，不要无理由地打开回收工作进程和使用工作进程池。一般理由通常是有不明原因的内存泄露、线程挂起等。