在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 的通信以处理请求。因为可重叠关闭或启动的关闭超时值是可以配置的，所以在工作进程仍在处理请求的同时可以终止该进程（如果它在时间限制内没有处理完请求 的话）。
在配置应用程序池以基于运行时间来回收工作进程时，可以在设置的运行时间内回收所有的工作进程，但不能同时回收所有这些工作进程。可以在设置的时间内的不同时段进行回收应用程序，以减少客户端请求服务的中断次数。
类似地，在配置应用程序池以基于处理请求的数目来回收应用程序时，可以每隔一段时间回收一次以分担与工作进程回收有关的系统开销。
