收藏
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服務器操做員的人爲干預。 一般您就應知道有人正在努力解決此問題,正常服務將被儘快恢復。
請和您網站的系統操做員聯繫,以肯定爲何服務中止了。 和咱們比起來,他們將能更好地幫您解決這類錯誤。
詞條標籤:
計算機學 , 互聯網