IIS6.0应用程序池回收

本文介绍了IIS6.0应用程序池回收的问题,分析了因程序资源占用过大导致的服务器故障。通过设置最大使用内存自动回收,解决了内存泄漏导致的进程崩溃。同时讨论了不同回收策略的影响,如请求数目、运行时间和计划时间,并分享了配置回收策略的经验。
摘要由CSDN通过智能技术生成

这段时间公司的程序经常出现问题,然后整个应用程序就不能访问了,我们的服务器版本:window 2003 SP1,IIS6.0,没有安装Microsoft Visual Studio .NET 。

问题如下:

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个可是
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值