如何回收IIS应用程序池?

如何回收IIS应用程序池?  

如何回收IIS应用程序池? 11小时前

　　把程序对应的IIS应用程序池回收一下就行了。

　　但是为何会出现这个缘由呢？还有为何回收一下就行了呢？回收作了些什么？

　　出现的缘由

　　在网上搜索了一翻，发现主要是一下几个问题，固然还有其余缘由

　　1）.Framework的问题，例如1.0和2.0版本

　　2）aspnet_wp.exe 问题

　　3）安全更新程序 (KB886903)

　　惋惜咱们服务器出现的问题都不是以上几点引发的，通过个人分析认为是写的很烂很烂的程序占用了大量的资源最后致使内存泄漏，致使IIS的进程当掉了。惋惜了程序我是没办法改，都是别人写的，也不会改。不过我不可能每次出现这个问题就登录到远程服务器上去回收一次吧，因此只有让他自动回收了。

　　自动回收有好几种方式，也不知道那一种比较适合，并且回收工做进程是会把保存在内存里的Session清空，形成用户须要从新登录的问题，因此自动回收要越少越好，以保证不会由于其中的一个用户使用了那个很烂的程式致使其余的用户都要从新登录。

　　若是用了状态服务器或者是把Session保存到了数据库中去的程序自动回收后确定是没有任何影响的，请求也不会中断仍是同样继续运行，只是换了个工做进程继续为客户端工做，客户端是感受不到的，当初没有为了方便没有把Session保存到数据库真是失策！

　　根据运行时间

　　系统默认是1740分钟,也就是29个小时,这个不是很好控制,建议不用，也就是去掉那个勾。

　　请求数目

　　这个要看具体的状况了。若是只有10个请求，但是有5个都在请求那个比较占资源的页面（多是统计年度报表之类），这个时候就会出现进程当掉的状况，若是请求有1000个但是一个也没运行比较占资源的页面，这个时候进程确定是很正常的，因此根据请求的数目来决定也不符合实际须要。

　　计划的时间

　　这个其实很好，不过具体什么时间回收好呢？一般咱们都是设置上班前和下班后回收，这个时候回收是有必要的，不过针对出现随时可能出现是高内存占用并非很适用。

　　内存（虚拟内存或已使用的内存）

　　这个针对出现内存问题引发的进程当掉实在太合适了，不过设置多大的值比较好是一个很重要的问题，我是根据每次出现问题时进程是实际占用状况决定的。咱们的服务器内存是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) 应用程序。

　　您所主控的应用程序已通过彻底测试，而且不会出现内存或资源分配问题。

　　要有效地使用回收，请仔细检查回收所依据的标准（以下表中所示）。

　　回收依据的条件 描述 使用时间

　　ISAPI 请求 根据应用程序池中 ISAPI 的请求回收工做进程。 ISAPI 扩展能够将其自身声明为运行情况差。

　　运行时间 根据用户指定的时间（分钟）回收工做进程。 存在故障的应用程序的运行时间过长。

　　请求数目 当超文本传输协议 (HTTP) 请求超出某个特定阈值时回收工做进程。 根据应用程序接收到的请求数目，应用程序出现故障。

　　计划的时间 在 24 小时内的指定时间进行回收。 条件与运行时间的条件相似。

　　虚拟内存（保留的内存加上已使用的内存） 当工做进程虚拟内存达到某个特定阈值时回收该工做进程。 内存堆栈碎片过多（这是因为应用程序保留屡次内存形成的）。症状是虚拟内存持续增长。

　　已使用的内存 当 W3wp.exe 进程使用的内存达到某个特定阈值时回收工做进程。 某些应用程序出现内存泄漏。

　　根据须要 当 IIS 管理员可使用 Microsoft&reg; 管理控制台 (MMC) 或脚本控制整个应用程序池的回收时开始回收。 在其余站点启动并运行时，有一个引发故障的应用程序池。请考虑回收该应用程序，而无需重置整个 WWW 服务。

　　系统中iis(微软的WEB服务器平台)日志：

　　　　应用程序:ISAPI ’C:\WINDOWS\system32\inetsrv\asp.dll’ 报告它自身有问题，缘由以下: ’ASP 不正常，由于执行请求的 100% 被挂起，并且请求队列已经使用了 0%。’。

　　　　关于server 2003+iis(微软的WEB服务器平台)6 出现 ’ASP 不正常，由于执行请求的 100% 被挂起

　　现象以下:

　　　　站点没法打开,或者打开很慢.HTML能够打开.从新启动或者回收应用程序池可恢复.但过一段时间又会出现

　　日志里会有:

　　　　ISAPI ’C:\WINDOWS\system32\inetsrv\asp.dll’ reported itself as unhealthy for the following reason: ’ASP unhealthy because 100% of executing requests are hung and 6% of the request queue is full.’.

　　或者:

　　　　ISAPI ’C:\WINDOWS\system32\inetsrv\asp.dll’ 报告它自身有问题，缘由以下: ’ASP 不正常，由于执行请求的 100% 被挂起，并且请求队列已经使用了 0%。’。

　　解决方法:

　　　　1.asp是否正确映射到’C:\WINDOWS\system32\inetsrv\asp.dll’

　　　　2.通常来说,是因为在同属iis(微软的WEB服务器平台)的应用程序池出现了某个站ASP代码错误所致,使得内存耗尽,检查代码自己的问题.能够隔离到单独应用程序池调试

　　　　三、减小应用程序池回收时间。默认为：1740。。可设为120（每2小时）

　　iis(微软的WEB服务器平台)假死的缘由：

　　　　打开iis(微软的WEB服务器平台) 你就会看到应用程序池，默认只有一个应用程序池，查看应用程序池的属性，会发现他的回收时间，默认多达，1740分钟，就是说，须要在1740分钟后才回收此应用程序池，若是在这个时间内，达到请求的最高限制，那么就会出现ASP假死的状况，这个就是大型网站出现假死的状况，反而，小型网站确不会出现这样的状况，由于他请求少，流量少，还没达到限制数量。固然要看你的服务器上网站数目而定。

　　如下是解决方法:

　　　　资料一

　　　　单个网站解决方法:

　　　　把应用程序池回收时间缩短到300-600分钟，其间回收过程当中，须要占用一点CPU资源，没办法，为了稳定性，再把回收时间设为凌晨5点。

　　多网站解决方法：

　　　　视服务器网站的多少，新建多个应用程序池，把每一个池回收时间缩小到300分钟，而后再分配每一个池10个网站左右(这个分配是要求你的网站访问量所定)若是某个网站，访问量大，就单独给他一个程序池，可是这样作的后果就是须要大内存，一个池如今占用我120M内存左右，反正内存大，不要紧，

　　　　那么多网站如何分配应用程序池，打开iis(微软的WEB服务器平台)--查看你要分配的网站属性，查看主目录--在下面你就会看到应用程序池了，分配一个就好了。

　　资料二

　　　　你们在使用iis(微软的WEB服务器平台)6时..若是装了动网论坛.确定有出现过iis(微软的WEB服务器平台)6假死现像..就是asp网页打开慢..可是iis(微软的WEB服务器平台)倒是正常的..静态网页打开速度同样..这时候..我一直是重启的方法..查了官方的资料结果没有...据官方资料说..win2003很快就要打这个补丁了..是iis(微软的WEB服务器平台)6对access(小型网站之最爱)驱动支持不理像..也算是一个bug吧..因为个人服务器虚拟主机多..并且大多支持asp..若是一旦假死就没法运行..在多方面的资料查找下..找到了一个比较简单的方法..具体我测试是经过了..iis(微软的WEB服务器平台)6自带数据应用程序池..如今就利用他来解决假死..

　　　　首先把bbs设一个单独的目录..而后点击应用程序池..新建应用程序池.输入应用程序池id..

　　　　而后把bbs的虚拟目录下面的.就用程序池..选择刚才新建的应用程序池...

　　　　而后再回到刚才设好的应用程序池...点击..属性...把回收工做进程数(分钟)及回收工做进程数还有在下列时间回收时间进程勾上..而后在下列时间回收程序池里左边添加..选择一个时间..通常来讲..网站到凌晨3点的时候.基本人都不多了..这时回收一下bbs的进程数..就能够解决了iis(微软的WEB服务器平台)假死的现像..

　　　　固然还能够配置其余信息..好比说iis(微软的WEB服务器平台)6的用户名.. 咱们能够打开计算机管理..而后打开计算机用户管理..添加一个用户..设置好后..在应用程序池里面..标识..把添加的用户放上去..用用户来测试回收的进程..固然还有..其余配置..其实很简单..只要好好看一下..就能明白意思...

　　　　也能够借助专用的工具来回收应用程序池..这样方便并且快捷..iis(微软的WEB服务器平台)的备份.虚拟主机ip的统一修改及端口访问的ip记录..用批处理是一个很简单又方便的方法.因此.把一台服务器作的安全..并非哪么容易的事..特别是iis(微软的WEB服务器平台)..常常去官方网站搜索资料是一