问题如下：
1.网页上显示
您试图在此 Web 服务器上访问的 Web 应用程序当前不可用。请点击 Web 浏览器中的“刷新”按钮重试您的请求。
管理员注意事项:
详述此特定请求失败原因的错误信息可在 Web 服务器的系统事件日志中找到。请检查此日志项以查明导致该错误发生的原因。
2.windows事件查看器-应用程序Log
The 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保存到数据库真是失策！
1.根据运行时间
系统默认是1740分钟,也就是29个小时,这个不是很好控制,建议不用，也就是去掉那个勾。
2.请求数目
这个要看具体的情况了。如果只有10个请求，可是有5个都在请求那个比较占资源的页面（可能是统计年度报表之类），这个 时候就会出现进程当掉的情况，如果请求有1000个可是一个也没运行比较占资源的页面，这个时候进程肯定是很正常的，所以根据请求的数目来决定也不符合实 际需要。
3.计划的时间
这个其实很好，不过具体什么时间回收好呢？通常我们都是设置上班前和下班后回收，这个时候回收是有必要的，不过针对出现随时可能出现是高内存占用并不是很适用。
4.内存（虚拟内存或已使用的内存）
这个针对出现内存问题引起的进程当掉实在太合适了，不过设置多大的值比较好是一个很重要的问题， 我是根据每次出现问题时进程是实际占用情况决定的。我们的服务器内存是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" //最大虚拟内存MB
PeriodicRestartPrivateMemory="1000" //最大占用内存MB
PeriodicRestartRequests="1000" //请求数
PeriodicRestartSchedule="07:50 //自动回收时间
12:00
20:00"
>
</IIsApplicationPool>
以下是摘录IIS自带的帮助。
工作进程回收如何工作
根据应用程序池回收的配置方式，万维网发布服务（WWW 服务）可以使用两种方法来回收已分配的工作进程：
•默认情况下，WWW 服务建立“重叠回收”，即继续运行要终止的工作进程，直到启动新的工作进程后为止。
•或者，WWW 服务可以终止一个工作进程，然后启动一个新的工作进程（如果工作负荷允许执行此操作的话）。
注意 当 WWW 服务回收某个工作进程时，它并不断开现有的 TCP/IP 连接。HTTP 协议堆栈 (HTTP.sys) 建立并维护 TCP/IP 连接。
在重叠回收方案中，要回收的进程继续处理请求，同时 WWW 服务创建一个替代工作进程。在停止旧工作进程之前启动新的工作进程，然后将请求定向到新的进程。此设计可以防止服务中断，因为旧进程关闭前仍然保持与 HTTP.sys 的通信以处理请求。因为可重叠关闭或启动的关闭超时值是可以配置的，所以在工作进程仍在处理请求的同时可以终止该进程（如果它在时间限制内没有处理完请求 的话）。
在配置应用程序池以基于运行时间来回收工作进程时，可以在设置的运行时间内回收所有的工作进程，但不能同时回收所有这些工作进程。可以在设置的时间内的不同时段进行回收应用程序，以减少客户端请求服务的中断次数。
类似地，在配置应用程序池以基于处理请求的数目来回收应用程序时，可以每隔一段时间回收一次以分担与工作进程回收有关的系统开销。
何时使用工作进程回收
在决定是否启动工作进程回收时，应考虑以下常规指南。最佳的解决方案是修复引起故障的应用程序。但是，并非总能使用重新编码，尤其是运行的其他应用程序代码无法修改时。
回收依据的条件
描述
使用时间
ISAPI 请求
根据应用程序池中 ISAPI 的请求回收工作进程。
ISAPI 扩展可以将其自身声明为运行状况差。
运行时间
根据用户指定的时间（分钟）回收工作进程。
存在故障的应用程序的运行时间过长。
请求数目
当超文本传输协议 (HTTP) 请求超出某个特定阈值时回收工作进程。
根据应用程序接收到的请求数目，应用程序出现故障。
计划的时间
在 24 小时内的指定时间进行回收。
条件与运行时间的条件类似。
虚拟内存（保留的内存加上已使用的内存）
当工作进程虚拟内存达到某个特定阈值时回收该工作进程。
内存堆栈碎片过多（这是由于应用程序保留多次内存造成的）。症状是虚拟内存持续增加。
已使用的内存
当 W3wp.exe 进程使用的内存达到某个特定阈值时回收工作进程。
某些应用程序出现内存泄漏。
根据需要
当 IIS 管理员可以使用 Microsoft? 管理控制台 (MMC) 或脚本控制整个应用程序池的回收时开始回收。
在其他站点启动并运行时，有一个引起故障的应用程序池。请考虑回收该应用程序，而无需重置整个 WWW 服务。
1.网页上显示
您试图在此 Web 服务器上访问的 Web 应用程序当前不可用。请点击 Web 浏览器中的“刷新”按钮重试您的请求。
管理员注意事项:
详述此特定请求失败原因的错误信息可在 Web 服务器的系统事件日志中找到。请检查此日志项以查明导致该错误发生的原因。
2.windows事件查看器-应用程序Log
The 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保存到数据库真是失策！
1.根据运行时间
系统默认是1740分钟,也就是29个小时,这个不是很好控制,建议不用，也就是去掉那个勾。
2.请求数目
这个要看具体的情况了。如果只有10个请求，可是有5个都在请求那个比较占资源的页面（可能是统计年度报表之类），这个 时候就会出现进程当掉的情况，如果请求有1000个可是一个也没运行比较占资源的页面，这个时候进程肯定是很正常的，所以根据请求的数目来决定也不符合实 际需要。
3.计划的时间
这个其实很好，不过具体什么时间回收好呢？通常我们都是设置上班前和下班后回收，这个时候回收是有必要的，不过针对出现随时可能出现是高内存占用并不是很适用。
4.内存（虚拟内存或已使用的内存）
这个针对出现内存问题引起的进程当掉实在太合适了，不过设置多大的值比较好是一个很重要的问题， 我是根据每次出现问题时进程是实际占用情况决定的。我们的服务器内存是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" //最大虚拟内存MB
PeriodicRestartPrivateMemory="1000" //最大占用内存MB
PeriodicRestartRequests="1000" //请求数
PeriodicRestartSchedule="07:50 //自动回收时间
12:00
20:00"
>
</IIsApplicationPool>
以下是摘录IIS自带的帮助。
工作进程回收如何工作
根据应用程序池回收的配置方式，万维网发布服务（WWW 服务）可以使用两种方法来回收已分配的工作进程：
•默认情况下，WWW 服务建立“重叠回收”，即继续运行要终止的工作进程，直到启动新的工作进程后为止。
•或者，WWW 服务可以终止一个工作进程，然后启动一个新的工作进程（如果工作负荷允许执行此操作的话）。
注意 当 WWW 服务回收某个工作进程时，它并不断开现有的 TCP/IP 连接。HTTP 协议堆栈 (HTTP.sys) 建立并维护 TCP/IP 连接。
在重叠回收方案中，要回收的进程继续处理请求，同时 WWW 服务创建一个替代工作进程。在停止旧工作进程之前启动新的工作进程，然后将请求定向到新的进程。此设计可以防止服务中断，因为旧进程关闭前仍然保持与 HTTP.sys 的通信以处理请求。因为可重叠关闭或启动的关闭超时值是可以配置的，所以在工作进程仍在处理请求的同时可以终止该进程（如果它在时间限制内没有处理完请求 的话）。
在配置应用程序池以基于运行时间来回收工作进程时，可以在设置的运行时间内回收所有的工作进程，但不能同时回收所有这些工作进程。可以在设置的时间内的不同时段进行回收应用程序，以减少客户端请求服务的中断次数。
类似地，在配置应用程序池以基于处理请求的数目来回收应用程序时，可以每隔一段时间回收一次以分担与工作进程回收有关的系统开销。
何时使用工作进程回收
在决定是否启动工作进程回收时，应考虑以下常规指南。最佳的解决方案是修复引起故障的应用程序。但是，并非总能使用重新编码，尤其是运行的其他应用程序代码无法修改时。
在以下情况下考虑使用回收：
- 无法修复 Web 服务器上您所主控的有故障的应用程序。
- 遇到不能确定的或间断性的故障。
- 您怀疑应用程序由于性能监视的原因而泄漏内存。
- 先前已实施了临时性的重置解决方案，例如，计划执行 IISReset 命令行实用工具。
在以下情况下，可能根本不需要使用回收：
- 您所主控的网站只包含静态内容，并且不包含自定义 Internet 服务器 API (ISAPI) 应用程序。
- 您所主控的应用程序已经过完全测试，并且不会出现内存或资源分配问题。
要有效地使用回收，请仔细检查回收所依据的标准（如下表中所示）。