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

問題：

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

回答：

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

Server is too busy = 服務器繁忙

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

重啟iis，cmd中輸入 iisreset /restart

那么這種情況應該如何解決呢？分為兩種情況：

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

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

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

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

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

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

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

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

ASP.NET性能調整之解決Server Too Busy錯誤

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

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

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

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

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

原來默認的是<processModel autoConfig="true"/>
改為<processModel maxWorkerThreads="200" maxIoThreads="200"/>

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

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

最新評論