Rss & SiteMap

康柏仕电脑学院 index.asp

康柏仕电脑学院--台湾正航ERP软件售后技术论坛,客服热线0769-81158210
共1 条记录, 每页显示 10 条, 页签: [1]
[浏览完整版]

标题:IIS6 Service Unavailable 的问题

1楼
轻轻风聆 发表于:2009/2/12 14:51:29

刚安装的操作系统2003 sp2   iis6   ftp   域
新建站点后访问 提示Service Unavailable 程序是没问题的 我就加了个html页面
应用程序池启动不开
事件查看器里报了5个警报 一个错误
4个警报信息
为应用程序池 'AppPool #1' 提供服务的进程意外终止。进程 ID 是 '4956'。进程退出代码是 '0xffffffff'。
一个错误信息
应用程序池 'AppPool #1' 被自动禁用,原因是为此应用程序池提供服务的进程中出现一系列错误。

问:为什么我的网站有时会出现“Service Unavailable”的提示,刷新几下又可以访问。

答: 出现这种情况是由于您的网站超过了系统资源限制造成的,主要是流量太大或者程序占用资源太多。
1.流量太大  
比如您购买的是b002型基础型主机,该主机的额定流量是15G/月。如果您的网站每月流量在15G,每天流量在0.5G以下,则应该能正常访问。如果连续几天的访问量上升,流量超过0.5G/天,则该主机属于超负荷 运行。 超负荷运行情况下,则会出现有时能正常访问,有时被系统自动停止(Service Unavailable)的情况。 解决办法是:首先登录虚拟主机管理中心查看最近的访问统计和流量统计,看看流量有没有异常增加的情况,有时站内的个别RAR或者mp3文件被其他网站盗链,则会出现流量上升几十倍的情况。通过我们提供的日志下载功能和访问统计中的"文件类别"功能进行分析,可以得出是否有盗链或者被大量下载。如果是流量自然增长,购买的型号不能满足要求,则需要对虚拟主机型号进行升级,以获得更多的流量配额。  
2.程序占用资源过多
比如同样是100人在线的论坛,雷傲论坛所占的资源就是动网论坛所占资源的10倍以上;另外,一些死循环程序,或者不优化的程序(比如1.0版的阿江统计在数据库太大的情况下)都会占用太多的系统资源,而系统资源明显是有限的。由于我们的新虚拟主机是采用WINDOWS2003的操作系统,各网站之间是以独立进程运行的,不会相互影响。

     如果一个网站的程序占资源太多或者发生太多的错误,系统日志就会提示:“应用程序池 'west263pool11' 被自动禁用,原因是为此应用程序池提供服务的进程中出现一系列错误,   或者提示:应用程序池 'hui999' 超过了其作业限制设置。有关更多信息,请参阅在 http://go.microsoft.com/fwlink/events.asp 的帮助和支持中心。
这时,访问这个网站就会提示:Service Unavailable。一般系统会在30秒左右恢复正常,多刷新几次就能正常访问了。
    如果经常出现类似的错误,请及时优化网站程序,或者升级你的虚拟主机至更高的款型,以获得更多的系统资源。  

程序占用资源太多的原因如下:
1.有一个或多个ACCESS数据库在多次读写过程中损坏,微软的MDAC系统在写入这个损坏的ACCESS文件时,ASP线程处于BLOCK状态,结果其他线程只能等待,IIS被死锁了,全部的CPU时间都消耗在DLLHOST(ASP进程)中。  
参考解决办法:  
压缩和修复我的数据库
下载数据库文件--[如果是.asp的扩展名,请改为.mdb的扩展名]--用ACCESS打开--选择工具--数据库实用工具--压缩和修复数据库--[改回.asp的扩展名]--上传覆盖原来数据库文件
         
2.注册了不良的Com组件,特别是用VB开发的ACTIVE X控件,可能导致占用内存使用量不断增长
参考解决办法:尽量减少或避免非官方或是客户要求的不必要的组件
3.多媒体等文件下载占用服务器带宽
参考解决办法:停止下载
4.程序问题
需要及时的关闭不再使用的数据库,以避免一直占用服务器资源 在conn.asp 连接数据库字符串语句中加入如下 sub endConnection() conn.close set conn=nothing end sub  
其它程序问题:把IE选项里 显示友好HTTP错误信息 的勾取消掉,再访问网站看出现什么错误信息,然后再调试  
5.上传重要的数据库等文件更新,由于正处于受访问状态,可能导致瞬间占用率上升
一般此情况较少,若有出现此情况时,可能有必要先暂停站点,再作更新 
6.ACCESS论坛(如动网)大了以后就很容易出现数据库方面的问题,当你的论坛数据库在30M以上,帖子5万左右,可能就会出现数据库吃不消的情况
         
7.建议取消程序中使用的on error resume next这个容错语句,对错误进行调试。 临时解决办法:定期删除多余的数据、压缩数据库,限制论坛灌水,甚至限制论坛注册。如果是动网论坛,可以使用论坛自带的分表储存功能,会有较好的效果
比较长远办法:更换论坛和数据库,一般都采用动网sql商业版本+MSSQL 的方案来解决

205上经常有Service Unavailable错误

因为出现Service Unavailable错误而使网站不能访问;
查看系统日志,发现
1、为应用程序池“DefaultAppPool”提供服务的进程在与World Wide Web Publishing 服务通信时遇到致命错误,进程ID为“3984”,数据字段包含错误号;
这警告出现5,6个后,
2、应用程序“DefaultAppPool”被自动禁用,原因是此应用程序池提供服务的进程中出现一系列错误

查找一些资料,说是需要回收一下进程,于是设置应用程序池的回收为每天的6:30;
另外也不排除网站程序出错的可能,于是首先将繁体版的网站运行到应用程序池apppool_GB5上,看看下次Service Unavailable会出现在哪个应用程序池,如果apppool_GB5上出现错误,说明繁体版网站有问题,如果还是DefaultAppPool错误的那继续将其下的其他分站点转移出来,一个个排查

请参考微软的KB885654,里面有详细的解决方案。
http://support.microsoft.com/Default.aspx?id=885654


为什么网站上不去了?出现Service Unavailable 这样的错误!

1:)未设置程序池的原因
    您可以将您的FTP用户明给我们 一下。我们帮您查找一下看看您的程序池是否开通。或者您的客户名是不是您自己的,如果不是我们会给您一个新的程序池
2:)频繁出现Service Unavailable 这样的错误,请提醒客户是不是在网站中有特别的程序,比如奇虎溲索之类,这些软件也会与IIS发生冲突。导致程序池死掉。

为什么网站上不去了?出现Service Unavailable 这样的错误!

1:)未设置程序池的原因
    您可以将您的FTP用户明给我们 一下。我们帮您查找一下看看您的程序池是否开通。或者您的客户名是不是您自己的,如果不是我们会给您一个新的程序池
2:)频繁出现Service Unavailable 这样的错误,请提醒客户是不是在网站中有特别的程序,比如奇虎溲索之类,这些软件也会与IIS发生冲突。导致程序池死掉。

为什么网站上不去了?出现Service Unavailable 这样的错误!

1:)未设置程序池的原因
    您可以将您的FTP用户明给我们 一下。我们帮您查找一下看看您的程序池是否开通。或者您的客户名是不是您自己的,如果不是我们会给您一个新的程序池
2:)频繁出现Service Unavailable 这样的错误,请提醒客户是不是在网站中有特别的程序,比如奇虎溲索之类,这些软件也会与IIS发生冲突。导致程序池死掉。

这两天,服务器从出现Service Unavailable错误,也不知道什么原因,又看了看转嘟嘟的一篇文章当时还没有遇到这样的情况,感觉自己的访问量等等应该还达不到,就没有去注意它,谁知...
从上个星期出错自己就有预感,上个星期是空间放的程序太多导致服务器死掉,这次呢?服务器刚刚修复登陆[URL-http://www.xyforever.org]http://www.xyforever.org下的网站就会出现Service Unavailable错误,自己也不清楚是怎么回事.难道每日的这么一点访问量就超过最大连接数了?和空间提供商交涉无数次,给我的答复是空间中程序放的太多,导致服务器死掉,可能吧.我对这些知道的并不是很多,就往里放了很多程序,论坛啊,BLOG啊,留言本啊等等,我就删除了一些没有用的程序,论坛也给转了,看了转嘟嘟的文章以后,发现自己也架设了计数器,两个,有一个就没用了,还有一个就是嘟嘟提供的阿江统计系统,原来它没隔40秒就向服务器提交,印证自己在线,严重影响服务器资源.这些删除后,在今天上午,又出现了Service Unavailable错误.天啊!可是刚刚修复好的啊,不会这么快吧.看了看,自己架设的SXNA也很占系统资源,1800秒一次首页读取,这样下来只要自己稍稍大一点访问就会导致服务器Service Unavailable错误,哎,删掉,反正没什么用,只是方便罢了,以后用Blogonlis来收集RSS聚合吧,它的功能强大多了,一点不好就是全英文的,对于我这样......
好了,空间里就剩下一些HTML静态页面和一些以用ASP做后缀的静态页面,3个Blog,两个是刚挂上不久的,应该不会影响吧,而且静态页面居多,两个日记本,都是很小的,一般没人访问的.其他就没有了不知道这样能管多久不出现Service Unavailable错误。

   to:    gongshf(gong)     
   本地是正常运行,服务器是万网的.net服务器,晚上,凌晨网速快的时候一般正常,白天中午访问基本上就出错,第一次是找不到服务器错误,再刷新就是Service    Unavailable了,,问过几次了,他们说是程序有问题,导致应用程序池挂起,我现在首页除了一个简单的DATELIST其他都是静态图片文字什么的,还是经常出现这问题~~~~~~   
    
   下面是万网回复的信息,   
    
   客户您好!您的站点现在已经可以正常打开    但是由于页面中存在错误    所以请您与您的程序员联系解决    并请注意程序代码中    是否会有已知错误    如果有请尽量修改避免错误被执行    因为IIS6采用独立应用程序池    为了保证每一个站点能够正常运行    这样针对每个站点    都设置了    容错    与资源占用限制!如果贵站点一但出现了service    unavailable    那么问题很可能是由于错误网页过多    导致应用程序池由于发现的错误超过限制    而自动停止(自我保护)导致出现service    unavailable    并无法访问站点!


因为近期服务器流量增大,论坛有时候会出现Service Unavailable。
在我们进行扩容之前,你遭遇Service Unavailable,尤其是在回帖时,请千万不要按[后退]键,这样会丢失您刚刚输入的文字。此时您要默念“1,2,3,4,5,6,7,8,9,10”或者“中国古生物网一统天下”,之后按[刷新]键,或者键盘上面的[F5],就会看到一个窗口探出,问你要不要(重试)?当然要~~,然后奇迹发生了……帖子成功回复了~~~~~
如果还不行,请10秒后再刷新。


由恶意刷票引起的CPU100%问题,及IIS:Service Unavailable与应用程序池

这几天公司的服务器CPU高占100%,我被当作高手派去解决此问题,呵,开个玩笑,这是老大指定的任务。

一,现发W3WP.EXE进程占用CPU特别高,结束此进程后,马上又会产生一个同样的进程,直接导致CPU100%。
一般我们认为会是哪个网站执行了死程序,因为我们通常自己本机调试时会有这样的情况(在2000 SER环境中),但我们通常是高度好了才上传的,疑惑中……GOOGLE一下,发现说是应用程序池的问题。可是更改了应用程序池的配置,让其超过CPU90%就回收,但无效。

服务器环境为2003SER IIS6.0,装有PHP,JAVA环境。

一步一步来:

1) 先断开网络停止网站请求,发现CPU降下来了;
2) 停止所有的站点,开启网络;
3) 依次开启站点,查看是哪些站点吃性能这么厉害;
4) 发现两个站点开启后浏览会有CPU高点问题,于是先停止这两个站点,开启其他站点;
5) 从程序上先入手,是否有死程序:发现其中A站点因为使用了一个ACTIVX控件而直接导致客户端CPU高占100%,这一站点先查看,去除这个控件,但此站点上传已有一段时间,未发现服务死机现象,排除此站最大嫌疑之帽子,但先也先去除这个控件再说;
发现另一个站点只要一开启,但我自己未浏览即没有请求的情况下即CPU100%,想,这可能有来自我之外的大量请求;
6) 继续找这个站的原因,本地调试此站程序,未发现问题;
7) 查看此站IIS日志,惊人!四天的四声达3G。分析日志,发现来自同一URL的请求居然达几百万条。此URL是投票程序。莫非有人恶意刷票?答案是确定的,是刷票。投票使用GET方式提交,限制IP访问的方式来控制,但未见好的效果,这个刷票程序明显伪造了一批IP来刷票。
8) 更改此URL地址,暂时取消投票;重启IIS,限制此站最大连接数为100;再观察。
9) 却发现Service Unavailable错误,原因未知。GOOGLE一下。说是应用程序池的原因。不知如何更改这个。重启IIS好几次,无效。问MSN上的几个好友,未得到满意结果;
10) 删除此站,重建站点,解决。

最大问题是被人恶意攻击,我想这相当于DDOS,几百万的请求,普通的服务器哪吃得消?
经过两天的观察调试,在头晕脑胀的情况下,解决了问题。

以上是过程描述,我想也是解决方法,有遇上同类问题者参考。

共1 条记录, 每页显示 10 条, 页签: [1]

Copyright ©2005 - 2024 康柏仕电脑学院 清理缓存

正航ERP软件-企业ERP最佳选择! http://www.chidg.com  0769-81158210
Powered By Dvbbs Version 8.3.0
Processed in .02002 s, 2 queries.