上網(wǎng)查了一下，引起的原因主要是由于網(wǎng)站程序中連接數(shù)據(jù)庫的代碼沒有及時關(guān)閉造成的，這樣鏈接多了以后就會造成鏈接數(shù)據(jù)庫的鏈接到達(dá)峰值，不能再連接數(shù)據(jù)庫，于是iis就報server too busy 。

問題：

Server is too busy 是什么意思，怎么解決？

回答：

首先，從字面上的意思我們就可以看出：

Server is too busy = 服務(wù)器繁忙

比較簡單的臨時解決方法：

重啟iis，cmd中輸入 iisreset /restart

那么這種情況應(yīng)該如何解決呢？分為兩種情況：

1、如果您是訪客，那么請聯(lián)系網(wǎng)站管理人員（咨詢或告知該問題），再或者可能您訪問的時段網(wǎng)站流量較大，可以選擇過一會再試！
2、如果您是站長，自己的網(wǎng)站出現(xiàn)這種情況，請參照網(wǎng)站Service Unavailable的解決方法。另外，也可以查閱虛擬主機(jī)或IIS下Server is too busy的一些優(yōu)化方法。

一般來說，當(dāng)你的iis發(fā)生了諸如"http:1001 server is too busy"的錯誤時，是因為你的asp程序中開了過多的server.createobject請求，然后每一個請求都需要排隊等待直到他們確實被建立了為止。

如果你的隊列的最大長度為500的話，當(dāng)隊列中已經(jīng)存在了499個請求時，這時如果第500個請求到達(dá)了，就會發(fā)生“server is too busy”錯誤。

那么怎么來使正在申請的請求最小化了，并且如何提高響應(yīng)時間呢，下面是幾個建議：

1.盡量使用.htm后綴的文件，避免使用.asp(尤其是在那些有可能招成超負(fù)荷的條件的特殊事件時)。因為htm不會障塞服務(wù)器同時能夠得到最大的緩存性能。(有關(guān)這個的效率問題我曾經(jīng)介紹過一篇文章，在精華區(qū)中)
2.盡量在你的asp中少使用server.createobject
3.嚴(yán)格限制你的asp調(diào)用不在你服務(wù)器上的外部資源，例如你的資源在另外一臺服務(wù)器上
4.盡量優(yōu)化你的網(wǎng)絡(luò)性能和穩(wěn)定性，例如增強(qiáng)你的后臺的sql server數(shù)據(jù)庫或則遠(yuǎn)程文件共享的局域網(wǎng)性能。
5.盡量讓每一個組件的執(zhí)行速度快與調(diào)用它的速度.例如，一個組件一秒鐘被調(diào)用了20次，那么它就必須在1/20秒的時間內(nèi)執(zhí)行完成，否則該組件將會阻塞。要知道，一個阻塞的組件將會導(dǎo)致你網(wǎng)站上所有的asp崩潰
6.每個禮拜都要監(jiān)視你的網(wǎng)站的性能狀態(tài).因為單個能夠產(chǎn)生阻塞的對象能夠?qū)δ愕恼麄€網(wǎng)站產(chǎn)生很不好的影響。

但是查看代碼固然重要，關(guān)鍵是要及時解決不能訪問的問題，于是采取了如下解決方法：

1.首先保證網(wǎng)站可以在第一時間恢復(fù)正常：
a：將sql數(shù)據(jù)庫服務(wù)器關(guān)閉，在啟動。
b：將iis重啟.這樣操作之后至少可以保證網(wǎng)站可以馬上瀏覽。

2.將iis應(yīng)用程序池的回收內(nèi)存減小。見到200mb左右。訪問量在30萬每天的情況下。應(yīng)該是5分鐘就能回收一次。避免鏈接數(shù)據(jù)庫的鏈接到大峰值。
3.查找沒有斷開連接的代碼，將連接及時關(guān)閉。

ASP.NET性能調(diào)整之解決Server Too Busy錯誤

最近公司的一個ASP.NET站點(diǎn)頻繁出現(xiàn)Server Too Busy錯誤，具體表現(xiàn)為頁面響應(yīng)慢、經(jīng)常出現(xiàn)Server Too Busy異常；但實際上服務(wù)器的資源消耗卻很低，CPU使用只有10%左右，非常奇怪。

該站點(diǎn)運(yùn)行環(huán)境為Windows 2000，IIS5.0，.NET Framework 1.1，站點(diǎn)壓力約為每秒10個連接，峰值時約為30。
從網(wǎng)上查找相關(guān)資料后，從表現(xiàn)出的情況來看（響應(yīng)慢，拋出Server Too Busy異常），初步判斷為同時連接過多引起的線程阻塞引起。修改web.config中的httpRuntime配置節(jié)中的appRequestQueueLimit參數(shù)后，Server Too Busy 的錯誤得到解決。此參數(shù)默認(rèn)從machine.config中繼承，默認(rèn)值為100，改為1000后Server Too Busy的錯誤不再出現(xiàn)。

雖然服務(wù)器忙的錯誤解決了，但是站點(diǎn)響應(yīng)還是很慢，有時候要等上5—10秒才能打開頁面。分析原因應(yīng)該是同時請求過多，而IIS工作線程不足的原因引起，修改machine.config中processModel配置節(jié)maxWorkerThreads參數(shù)為200后站點(diǎn)響應(yīng)速度慢的問題得到解決。此參數(shù)默認(rèn)值為20，可根據(jù)服務(wù)器硬件配置于壓力大小適當(dāng)調(diào)整。

分析原因，是因為站點(diǎn)程序中使用了HttpWebRequest請求外部服務(wù)器的頁面，而這個操作是相當(dāng)耗時的（外部服務(wù)器響應(yīng)慢是主要原因）。當(dāng)訪問者的請求到達(dá)ASP.NET工作進(jìn)程后，ASP.NET首先會檢查是否有空余的工作線程（WorkerThread），如果有的話，就交給一個空閑的工作線程去處理，如果沒有空閑的工作線程，那么這個請求就會被放到請求隊列（RequestQueue）中，這個時候的表現(xiàn)就是響應(yīng)很慢。當(dāng)訪問量過大導(dǎo)致請求隊列也滿了的時候，ASP.NET就會拋出Server Too Busy異常了。在.NET 1.1中，默認(rèn)的工作線程和請求隊列分別為20和100，當(dāng)運(yùn)行的代碼比較費(fèi)時而訪問量又較大的時候，這兩個默認(rèn)值顯然就太小了。（現(xiàn)在的服務(wù)器硬件便宜了，一般PC服務(wù)器的吞吐量都應(yīng)該遠(yuǎn)超過這個數(shù)）。這兩個值可以根據(jù)服務(wù)器壓力大小來進(jìn)行合理配置。以調(diào)整站點(diǎn)吞吐量。
httpRuntime Server Too Busy

修改方法：修改服務(wù)器.net配置“machine.config＂文件，該文件位于Windows系統(tǒng)目錄下，如“C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFIG　”，視你的網(wǎng)盤程序版本，修改對應(yīng)目錄下的machine.config文件，如2.0版本用戶就修改“C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG”下的machine.config文件，查找該文件中的“processModel”配置段落，修改其中的字段maxWorkerThreads="200" maxIoThreads="200"，1.1和2.0的默認(rèn)段落不太一樣，修改后的配置如下：
1.1版本：

<processModel
enable="true"
timeout="Infinite"
idleTimeout="Infinite"
shutdownTimeout="0:00:05"
requestLimit="Infinite"
requestQueueLimit="5000"
restartQueueLimit="10"
memoryLimit="60"
webGarden="false"
cpuMask="0xffffffff"
userName="machine"
password="AutoGenerate"
logLevel="Errors"
clientConnectedCheck="0:00:05"
comAuthenticationLevel="Connect"
comImpersonationLevel="Impersonate"
responseDeadlockInterval="00:03:00"
maxWorkerThreads="200"
maxIoThreads="200"
/>

2.0版本：

原來默認(rèn)的是<processModel autoConfig="true"/>
改為<processModel maxWorkerThreads="200" maxIoThreads="200"/>

不用重新啟動服務(wù)器就可以看到效果。

以上只是個人實踐體會，我的服務(wù)器狀態(tài)是：２００３操作系統(tǒng)，

最新評論