[原创]关于IIS6.0ASP假死问题的重新考虑与认识(完整篇)
文章标题:[
原创]关于IIS6.0ASP假死问题的重新考虑与认识(完整篇)顶部 勇敢的风 发布于:2005-05-0122:15 [楼主][原创]关于IIS6.0ASP假死问题的重新考虑与认识(完整篇)
文章作者:勇敢的风[E.S.T顾问团]
信息来源:邪恶八进制安全小组
这个问题已经困扰我很久了,由于时间太长我也记不起来到底有多久了,反正很长时间。近来由于我的针对个人提供空间服务的站点《个人家园》再次出现该问题,我不得不对此问题重新考虑。
以前在MS的官方站点上
搜索到关于ASP假死的一个解决方法:support.microsoft/default.aspx?scid=kb;zh-cn;831464在看到该补丁前的解决方法是采用IIS5隔离模式,看到该补丁后原以为
问题该解决了,可是还是不行。
这些天在看系统Ri志的时候发现每当ASP假死后在
系统Ri志中会出现一条错误信息和一条警告信息,如下:
=============================================================
错误信息:
服务WorldWideWebPublishingService意外停止。这发生了2次。
来源:ServiceControlManager
-------------------------------------------------------------
警告信息:
为应用程序池&;#39;DefaultAppPool&;#39;提供服务的进程ID为5088的worker进程已经请求回收,因为worker进程达到了允许的运行时间限制。
来源:W3SVC
=============================================================
看到以上信息再结合原始的解决方法,猜想该问题为应用程序池造成的,因为采用隔离模式时是没有应用程序池的,于是开始寻找有关于应用程序池的资料,并得到一下认识:
1、工作进程:靠,真不知道MS是怎么起名的,命名是ASP的Session所产生的连接数,他却叫做工作进程。
2、回收
工作进程:清空所有采用该应用程序池的站点中当前使用Session对象。
3、解决方法应该就是怎么回收(猜想);
于是将应用程序池中的回收方式做一下修改:只采用定时回收的方法,在0:00、12:00、19:00三个时间进行回收。至于效果如何且看使用后分解。
(未完...)
-------------------------------------------------------------------------------------------------
(续)
经过一个多月的测试再未发现出错,说明该方法确实可行,简单总结一下:
1、以上设定有弊端:仅仅这样设定是不够的,因为当该应用
程序池下的站点越来越多时,以上设定可能将会出现问题。
2、对于访问量过大的站点应单独开设应用程序池。
3、每个应用程序池下设定的站点不要过多。
4、设定应用程序池应根据下设站点的总访问量来设定,不好意思的是我不知道多少的访问量应设定一个应用程序池。
[此贴被勇
敢的风在06-07-200511:14重新编辑]顶部 网路游侠 发布于:2005-05-0511:45 [1楼]
ASP挂掉的问题,2003出现的稍微多一些
但是Windows2000也有这种现象
2003可以通过应用程序池解决,2000呢?
有时候,好像帐号密码不同步居然也有这问题顶部 勇敢的风 发布于:2005-05-0617:46 [2楼]
关于这个问题我曾经看过,说是要重新修改3个地方的密码,具体的我记不清除了,顺便说一下我很少用2000的。顶部 softbug 发布于:2005-06-0908:28 [3楼]
IIS6采用隔离模式是不好的办法,他是以降低IIS的安全级别为代价的。
虽然可以工作了,但会出现问题(c)Copyleft2003-2007,EvilOctalSecurityTeam.
ThisfileisdecompiledbyanunregisteredversionofChmDecompiler.
Regsiteredversiondoesnotshowthismessage.
YoucandownloadChmDecompilerat:zipghost/