收藏
393
定义
因为临时的
服务器维护或者过载,服务器当前没法处理请求。这个情况
是临时的,而且将在一段时间之后恢复。若是可以预计延迟时间,那么响应中能够包含一个
Retry-After起头用以标明这个延迟时间。若是没有给出这个
Retry-After信息,那么客户端应当以处理500(
Server Internal Error)响应的方式处理它。注意:503状态码的存在并不意味着必须在
服务器过载的时候使用它。某些服务器只不过是但愿拒绝某些客户端的链接。
分析
出现503错误,其
日志都是记录在
%Systemroot%
\System32\LogFiles\HTTPERR\httperr1.log中。
其中的
s-reason项:
一、若为
AppShutdown,多是因为
CPU占用率过高致使自动关闭应用程序池。
二、若为
AppOffline,多是因为应用程序标识出错引发的。
三、若为
Disabled,多是由管理员手工关闭
应用程序池引发的。
四、若为
QueueFull,多是由于请求时应用程序池队列已满而生成该错误。
任何客户端在和您的网络服务器通信时,都需通过如下循环:
从您站点的 IP 名称 ( 即您的网页地址 - URL, 不带起始的 ‘http://') 得到一个 IP 地址。这个对应关系 ( 即由 IP 名称向 IP地址转换的对应关系 ) 由
域名服务器(DNSs) 提供。 打开一个 IP socket (
套接字) 链接到该 IP 地址。 经过该 socket 写 HTTP 数据流。 从您的
网络服务器接受响应的 HTTP 数据流。该数据流包括状态编码, 其值取决于 HTTP 协议 。 解析 该数据流获得 状态编码 和其余有用信息。 该错误在以上所述的最后一步生成,即当客户端收到 HTTP 状态编码 并识别其为 ‘503’ 时。
网页出现
二、当请求到达时应用程序池队列已满。
三、应用程序池标识没有使用预约义帐户:网络服务,而本身配置了标识,可是配置的这个用户不属于
IIS_WPG组
四、应用程序池启用了
CPU监视,而且设置了
CPU利用率超过必定百分比关闭应用程序池,而开发人员写的
服务端页面(
.
asp,.
aspx)执行效率不高,会引发
CPU的长时间占用,最终达到设置的百分比,从而引发应用程序池关闭
六、
web.config的
system.web/httpRuntime节点的
appRequestQueueLimit属性设置的值过低。
主机站点
主要缘由有两点:
一、该站点正在被攻击。对于最新型的攻击,实际上是
ddos的一种派生,原理在于找数千个IP,同时向
服务器的
apache发出请求,而后 当即断开,让
apache处于等待状态,导致
apache线程所有被填满,导致服务器死机。所以,为了保证大多数客户的利益,咱们给每一个 空间,做出了每19秒64个
php请求的限制。注意,是
php请求,通常的图片请求和
html请求不包括在内。
二、该程序占用的
php线程过多,有的程序没有进行好优化处理,一个点击便可产生数个,甚至数十个
php线程。这样的话,几个点击就能够把该时段的64个php线程所有填满了。所以出现503错误。建议优化一下程序,尽可能少用
require(“请求”之意)等语句。解决方案:
要解决此问题,按照下列步骤操做:
请按照下列步骤来肯定虚拟服务器正在使用的应用程序池。
a.单击“开始”,指向“管理工具”,而后单击“
Internet信息服务(IIS)管理器”。
b.展开“ServerName”,展开“Web站点”,右键单击虚拟服务器,而后单击“属性”。
c.单击“主目录”选项卡。为虚拟服务器配置的
应用程序池列在“应用程序池”框中。
d.单击“肯定”。
二、验证应用程序池账户使用的密码是否正确。IIS不会自动轮询ActiveDirectory目录服务中的密码更改。若是应用程序池账户是一个域账户,其密码已过时,则在为此账户从新指定一个新密码后,您可能会收到本文“症状”部分所描述的错误信息。
三、验证应用程序池账户是
服务器上的IIS_WPG组和STS_WPG组的成员。
四、从新启动
IIS以回收应用程序池。
您的 Web
服务器实际上处于“关闭维修”状态。 它仍然在最低限度地运行, 由于它至少能够响应 503 状态码, 但全面服务是不可能的, 即您的网站不可用。 可能的缘由有不少, 但通常来讲, 是因为您的 Web服务器操做员的人为干预。 一般您就应知道有人正在努力解决此问题,正常服务将被尽快恢复。
请和您网站的系统操做员联系,以肯定为何服务中止了。 和咱们比起来,他们将能更好地帮您解决这类错误。
词条标签:
计算机学 , 互联网