如何回收IIS应用程序池?

2019独角兽企业重金招聘Python工程师标准>>>

如何回收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代码错误所致,使得内存耗尽,检查代码本身的问题.可以隔离到单独应用程序池调试

　　　　3、减少应用程序池回收时间。默认为：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服务器平台)..经常去官方网站搜索资料是一

转载于:https://my.oschina.net/u/582827/blog/280152