-
Service Unavailable故障解决方法
2014年08月01日 安全技术 热度1707 查看评论
这两天一直在给服务器做定期维护,在进行软件配置时突然发现服务器上的一个新闻站点无法访问了,显示的是Service Unavailable的错误提示。
以为网站内有敏感词汇,被机房屏蔽了,又接连打开几个页面,一样的情况,觉得不会啊,就算有敏感词汇,屏蔽的也只是有出现敏感关键词的页面,不会所有页面都打不开的。难道情节严重,全站屏蔽?马上远程服务器测试,发现还是Service Unavailable。就算屏蔽只会外网无法访问,也不会连服务器上也打不开才对。又试了试同服务器的其它几个站点。发现都是同样的情况。纳闷不已,会不会是机房屏蔽了我的整个服务器?想想这个猜测也不成立:一、服务器本身没有任何问题,分分钟前还在远程管理。二、服务器上所有站点也没有任何违规违法信息,没理由封停。三、就算有情况严重到要封停服务器IP,事先也应该先通知我。
马上联系服务商,服务商查看后回复说,应用程序池停掉了。应用程序池是将一个或多个应用程序链接到一个或多个工作进程集合的配置。因为应用程序池中的应用程序与其他应用程序被工作进程边界分隔,所以某个应用程序池中的应用程序不会受到其他应用程序池中应用程序所产生的问题的影响。以上是百度百科的解释。简单来说应用程序池就是可以看成装载计算机分配给动态网站的内存的容器。如果内存是水,那么应用程序池就是鱼缸,动态网站就是鱼缸中的金鱼。多个动态网站可以存在于同一个应用程序池里,即鱼缸中可以放多条金鱼。当然,如果金鱼多了,鱼缸中的空间有限,金鱼之间就会争抢空间,不是很坚固的鱼缸可能就会破裂,所有金鱼都会受到影响。即动态网站多了,内存不足,可能会造成内存级别的溢出漏洞,影响所有在那个应用程序池上的动态网站。
好了找到原因了,不是因为别的原因被机房屏蔽。看来是服务器出现了点小状况,人好吃好喝都会生病,何况是机器。联系服务商帮忙程序启动应用程序池。半天后服务商的技术说启动不了,网站程序有问题..... 呃 居然还有技术解决不了的问题?再说我网站程序最近没做改动的说。郁闷不已,再三沟通,一直要我检查网站程序,这是?推卸责任?解决不了的问题都是网站程序的问题(反正服务器没问题,不知道是不是这意思)?没办法,自己动手丰衣足食。
一、故障分析
Service Unavailable的出现一般是因为资源不足,如IIS、CPU或内存等,极少数情况下会因asp 、.net和php程序错误导致出现。
如果一个网站的程序占资源太多或者发生太多的错误,系统日志就会提示:“应用程序池 'xxx' 被自动禁用,原因是为此应用程序池提供服务的进程中出现一系列错误,或者提示:应用程序池 'xxx' 超过了其作业限制设置。这时,访问这个网站就会提示:Service Unavailable。一般系统会在30秒左右恢复正常,多刷新几次就能正常访问了。
但我查看了系统日志,并未记录具体错误提示,几分钟后站点也未恢复正常访问,程序池也一直处于无法启用的状态,显然不是因为资源占用。
二、几种可能造成的故障原因(这是网上找到的几种比较常见的问题)
1:没有打SP1补丁的时候会出现这个IIS6.0假死问题,但现在微软都在自动更新里面出补丁了,一般你打好最新补丁后是不会出现此问题了
(最近服务器没有补丁更新,排除此项)
2:限制了应用池 的资源过小(应用程序池的资源大小并未限制,排除此项)
3:限制了内存使用(并未限制内存使用,排除此项)
4:服务器自身内存太小(服务器内存一直没有变动,用了好几年了,以前怎么没有问题?排除此项)
5:ACCESS数据库太大或查询太多(服务器上部分站点确实使用了access数据库,最大的也就十几MB,不存在过多,查询过多的问题,排除此项)
6:不同网站用不同应用池(我比较懒,这个还真心没有具体划分过,所有站点都是共同使用一个应用池,排除此项)
7:设置回收时间,很多人以为设置回收池越短越好,其实是错误的(回收池时间并未设置,不存在短不短的问题,排除此项)
8:网站有cc攻击(防火墙监测,并无cc攻击,排除此项)
以上几种情况经过排查,觉得都不符合我的故障。难道真的是因为网站程序错误?这不科学啊。好吧。安全起见,我挨个检查了所有站点的网站程序修改记录,没听错,是所有站点,成千上万个文件,累坏我了(感觉真2)。确定最近所有的网站的程序都没有任何改动!
三、另辟蹊径
那问题在哪?为什么无端就故障了呢? 早上还是好好的,突然就故障了。百思不得其解,求助万能的度娘。发现有个人的案例比较与众不同,他也是整个服务器上的所有站点都显示Service Unavailable错误。如下图:
和我的问题如出一辙,灵光一现,莫不是我的.net2.0有问题?或者说是筛选器的映射有错?想想出现问题之前我正在进行软件配置,没错,前两天服务商通知新闻网内有敏感词汇所以装了些监测敏感词汇的软件。用了几天感觉不好用,所以删除了,莫不是问题出在这里,想想可能性很大。先检查ISAPI筛选器映射。
四、解决问题
果然,如图所示,多了个 C:\Program Files\iiszj.com\IISzj_Free..... 这应该是之前的监测软件删除后留下的,因为卸载不干净,导致映射找不到路径,造成的程序错误。果断删除,重启下应用程序池,ok,顺利启动....刷新下网页,也恢复了正常访问。
结尾:这次的故障原因追究来还是因为第三方软件卸载不干净,配置不当造成的。因为维护时首先想到的是一些常见的故障原因,忽略了从自身操作的过程中,寻找答案。如果从正常访问到不能访问的时间段里,仔细回忆自己做过的所有操作(删除监测软件),应该不难想到是哪个环节可能出现了问题,也不至于耗费了大量时间去挨个检查(甚至检查成千上万的网站程序文件,这么2的行为)。得此经验,遂出此文。也同时给出现Service Unavailable一样故障的站长们,提供一条不同于常见故障原因的解决办法。
再次吐槽下服务商的技术部门,太不尽心了。作为为万千客户服务的专业人士,应该能对各种问题了如指掌,对各种故障应对自如,遇到技术难题连饭都吃不下才对(我就是这样),而不是一概推给客户,让客户检查网站程序!事实上这次故障和网站的程序代码毛关系都没!
相关日志:
- 搜索
- 文章归档
-
- 2023年7月 (19)
- 2023年6月 (20)
- 2023年5月 (4)
- 2022年11月 (11)
- 2022年10月 (9)
- 2022年7月 (22)
- 2022年6月 (39)
- 2022年5月 (17)
- 2022年4月 (1)
- 2017年3月 (1)
- 2016年11月 (1)
- 2015年11月 (6)
- 2015年8月 (24)
- 2015年7月 (43)
- 2015年6月 (28)
- 2015年5月 (34)
- 2015年4月 (38)
- 2015年3月 (35)
- 2015年2月 (28)
- 2015年1月 (31)
- 2014年12月 (14)
- 2014年11月 (8)
- 2014年10月 (8)
- 2014年9月 (7)
- 2014年8月 (13)
- 2014年7月 (22)
- 2014年6月 (26)
- 2014年5月 (14)
- 2014年4月 (16)
- 2014年3月 (13)
- 2014年2月 (17)
- 2014年1月 (23)
- 2013年12月 (19)
- 2013年11月 (18)
- 2013年10月 (17)
- 2013年9月 (15)
- 2013年8月 (21)
- 2013年7月 (15)
- 2010年8月 (1)
- 最近发表
- 站点信息
-
- 文章总数:782
- 页面总数:2
- 分类总数:14
- 标签总数:522
- 评论总数:359
- 浏览总数:624719