IIS内存回收

wlxmhls

　　自动回收有好几种方式，也不知道那一种比较适合，而且回收工作进程是会把保存在内存里的Session清空，造成用户需要重新登陆的问题，所以自动回收要越少越好，以保证不会因为其中的一个用户使用了那个很烂的程式导致其他的用户都要重新登陆。   
如果用了状态服务器或者是把Session保存到了数据库中去的程序自动回收后肯定是没有任何影响的，请求也不会中断还是一样继续运行，只是换了个工作进程继续为客户端工作，客户端是感觉不到的，当初没有为了方便没有把Session保存到数据库真是失策！     
根据运行时间     
系统默认是1740分钟,也就是29个小时,这个不是很好控制,建议不用，也就是去掉那个勾。     
内存（虚拟内存或已使用的内存）     
这个针对出现内存问题引起的进程当掉实在太合适了，不过设置多大的值比较好是一个很重要的问题，我是根据每次出现问题时进程是实际占用情况决定的。我们的服务器内存是2G，通常其他的一些服务会占用掉600多M，我发现有每次进程都是到1G多的时候当掉，所以设置了最大使用内存为1000M的时候自动回收，设置后一直都没出现问题了。要查看进程的占用直接用windows任务管理器就好，值不能太小了，否则如果访问量都很大超过这个值的时候也会自动回收，这个就很没必要了。一定要多多观察进程的实际占用情况再做决定。     
现在暂时根据最大占用内存自动收回以前的问题是解决了，暂时也发现什么新问题了，也不知道其他地方都是怎么设置的，是不是还有更好的方法呢？希望到了这篇文章的人能提点宝贵意见，大家一起交流一下经验。     
IIS的配置文件在windows的安装目录下（C:\WINDOWS\system32\inetsrv\MetaBase.xml），直接修改配置文件需要停止IIS服务，修改前记得备份。     
部分配置信息，写的好玩的     
<IIsApplicationPool    Location =&quot;/LM/W3SVC/AppPools/DefaultAppPool&quot;     
        AppPoolAutoStart=&quot;TRUE&quot;     
        PeriodicRestartMemory=&quot;2000&quot;  //最大虚拟内存MB     
        PeriodicRestartPrivateMemory=&quot;1000&quot; //最大占用内存MB     
        PeriodicRestartRequests=&quot;1000&quot; //请求数     
        PeriodicRestartSchedule=&quot;07:50  //自动回收时间     
            12:00     
            20:00&quot;     
    >     
</IIsApplicationPool>     
以下是摘录IIS自带的帮助。     
工作进程回收如何工作      
根据应用程序池回收的配置方式，万维网发布服务（WWW 服务）可以使用两种方法来回收已分配的工作进程：     
默认情况下，WWW 服务建立“重叠回收”，即继续运行要终止的工作进程，直到启动新的工作进程后为止。     
或者，WWW 服务可以终止一个工作进程，然后启动一个新的工作进程（如果工作负荷允许执行此操作的话）。     
注意 当 WWW 服务回收某个工作进程时，它并不断开现有的 TCP/IP 连接。HTTP 协议堆栈 (HTTP.sys) 建立并维护 TCP/IP 连接。     
在重叠回收方案中，要回收的进程继续处理请求，同时 WWW 服务创建一个替代工作进程。在停止旧工作进程之前启动新的工作进程，然后将请求定向到新的进程。此设计可以防止服务中断，因为旧进程关闭前仍然保持与 HTTP.sys 的通信以处理请求。因为可重叠关闭或启动的关闭超时值是可以配置的，所以在工作进程仍在处理请求的同时可以终止该进程（如果它在时间限制内没有处理完请求的话）。     
在配置应用程序池以基于运行时间来回收工作进程时，可以在设置的运行时间内回收所有的工作进程，但不能同时回收所有这些工作进程。可以在设置的时间内的不同时段进行回收应用程序，以减少客户端请求服务的中断次数。     
类似地，在配置应用程序池以基于处理请求的数目来回收应用程序时，可以每隔一段时间回收一次以分担与工作进程回收有关的系统开销。     
何时使用工作进程回收     
在决定是否启动工作进程回收时，应考虑以下常规指南。最佳的解决方案是修复引起故障的应用程序。但是，并非总能使用重新编码，尤其是运行的其他应用程序代码无法修改时。     
在以下情况下考虑使用回收：     
无法修复 Web 服务器上您所主控的有故障的应用程序。     
遇到不能确定的或间断性的故障。     
您怀疑应用程序由于性能监视的原因而泄漏内存。     
先前已实施了临时性的重置解决方案，例如，计划执行 IISReset 命令行实用工具。     
在以下情况下，可能根本不需要使用回收：     
您所主控的网站只包含静态内容，并且不包含自定义 Internet 服务器 API (ISAPI) 应用程序。     
您所主控的应用程序已经过完全测试，并且不会出现内存或资源分配问题。     
要有效地使用回收，请仔细检查回收所依据的标准（如下表中所示）。     
回收依据的条件     描述      使用时间     
ISAPI 请求：  根据应用程序池中 ISAPI 的请求回收工作进程。 ISAPI 扩展可以将其自身声明为运行状况差。     
运行时间：  根据用户指定的时间（分钟）回收工作进程。 存在故障的应用程序的运行时间过长。     
请求数目：  当超文本传输协议 (HTTP) 请求超出某个特定阈值时回收工作进程。 根据应用程序接收到的请求数目，应用程序出现故障。     
计划的时间：  在 24 小时内的指定时间进行回收。 条件与运行时间的条件类似。     
虚拟内存： （保留的内存加上已使用的内存） 当工作进程虚拟内存达到某个特定阈值时回收该工作进程。 内存堆栈碎片过多（这是由于应用程序保留多次内存造成的）。症状是虚拟内存持续增加。     
已使用的内存：  当 W3wp.exe 进程使用的内存达到某个特定阈值时回收工作进程。 某些应用程序出现内存泄漏。     
根据需要：  当 IIS 管理员可以使用 Microsoft® 管理控制台 (MMC) 或脚本控制整个应用程序池的回收时开始回收。 在其他站点启动并运行时，有一个引起故障的应用程序池。请考虑回收该应用程序，而无需重置整个 WWW 服务。
　　http://topic.iyunv.com/u/20090525/13/f1d14958-c2cc-4326-be1c-77112e1bb648.html