發(fā)生此問題是因?yàn)?Jet 數(shù)據(jù)庫引擎中存在缺陷。 Microsoft Windows Server 2003 上只會出現(xiàn)此問題。

1：使用 MicrosoftJet 數(shù)據(jù)庫引擎 Web 應(yīng)用程序可能停止響應(yīng)負(fù)載，造成假死：
原因：發(fā)生此問題是因?yàn)?Jet 數(shù)據(jù)庫引擎中存在缺陷。 Microsoft Windows Server 2003 上只會出現(xiàn)此問題。 在 Windows Server 2003, COM+ 更改頻率 CoFreeUnusedLibraries 函數(shù)被調(diào)用。 此更改導(dǎo)致 Jet 驅(qū)動程序以初始化頻繁。 此行為可能導(dǎo)致死鎖條件。
Web 服務(wù)器負(fù)載時最常出現(xiàn)此問題。
補(bǔ)丁下載：
chs:WindowsServer2003-KB838306-x86-chs.exe
enu:WindowsServer2003-KB838306-x86-enu.exe
在IIS6下，經(jīng)常出現(xiàn)w3wp.exe的內(nèi)存及CPU占用不能及時釋放，從而導(dǎo)致服務(wù)器響應(yīng)速度很慢。

解決內(nèi)存占用過多，可以做以下配置：
1、在IIS中對每個網(wǎng)站進(jìn)行單獨(dú)的應(yīng)用程序池配置。即互相之間不影響。
2、設(shè)置應(yīng)用程序池的回收時間，默認(rèn)為1720小時，可以根據(jù)情況修改。再設(shè)置當(dāng)內(nèi)存占用超過多少（如500M），就自動回收內(nèi)存。

解決CPU占用過多：
1、在IIS中對每個網(wǎng)站進(jìn)行單獨(dú)的應(yīng)用程序池配置。即互相之間不影響。
2、設(shè)置應(yīng)用程序池的CPU監(jiān)視，不超過25%（服務(wù)器為4CPU），每分鐘刷新，超過限制時關(guān)閉。

根據(jù)w3wp取得是那個一個應(yīng)用程序池：
1、在任務(wù)管理器中增加顯示pid字段。就可以看到占用內(nèi)存或者cpu最高的進(jìn)程pid
2、在命令提示符下運(yùn)行iisapp -a。注意，第一次運(yùn)行，會提示沒有js支持，點(diǎn)擊確定。然后再次運(yùn)行就可以了。這樣就可以看到pid對應(yīng)的應(yīng)用程序池。（iisapp實(shí)際上是存放在C:\windows\system32目錄下的一個VBS腳本，全名為iisapp.vbs，如果你和我一樣，也禁止了Vbs默認(rèn)關(guān)聯(lián)程序，那么就需要手動到該目錄，先擇打開方式，然后選“Microsoft (r) Windows Based Script Host”來執(zhí)行，就可以得到PID與應(yīng)用程序池的對應(yīng)關(guān)系。）
3、到iis中察看該應(yīng)用程序池對應(yīng)的網(wǎng)站，就ok了，做出上面的內(nèi)存或CPU方面的限制，或檢查程序有無死循環(huán)之類的問題。

QUOTE:

環(huán)境：win2003server+IIs+ASP+MSSQL

現(xiàn)象：每隔一段時間（不定，有時幾分鐘，有時半小時）出現(xiàn)一次網(wǎng)站打開非常緩慢，甚至有時會出現(xiàn)超時打不開站點(diǎn)，此時查看服務(wù)器端的進(jìn)程，CPU占用率達(dá)到100%，其中w3wp占用70~80%，SQL占用20~30%。所有服務(wù)器端的操作也變得緩慢。

初期解決方法：每次現(xiàn)象出現(xiàn)時，立即登錄服務(wù)器直接結(jié)束w3wp進(jìn)程或重啟IIS服務(wù)，平均每天約十次操作，由于服務(wù)器存放于遠(yuǎn)程機(jī)房，所有操作都是遠(yuǎn)程控制進(jìn)行，有時會因此出現(xiàn)遠(yuǎn)程無法連接登錄的情況，只能通過電話通知機(jī)房管理人員重啟服務(wù)器解決，此過程導(dǎo)致用戶抱怨不斷。

經(jīng)過網(wǎng)上查閱資料，發(fā)現(xiàn)此類現(xiàn)象多數(shù)由于網(wǎng)頁代碼不合理所致，以下情況會導(dǎo)致此類現(xiàn)象發(fā)生：
1、代碼中多處使用application、seesion等服務(wù)器緩存，導(dǎo)致服務(wù)器資料過度占用；
2、代碼有不合理語法，死循環(huán)等；
3、數(shù)據(jù)庫損壞，尤其是ACCESS數(shù)據(jù)庫；
4、裝過多第三方軟件或插件，與IIS或網(wǎng)頁功能代碼沖突。

第一階段排查：根據(jù)查閱到的參考資料逐項(xiàng)分析
1、服務(wù)器上所有站點(diǎn)代碼均為公司設(shè)計(jì)人員自行編寫，可證實(shí)并無過多調(diào)用服務(wù)器緩存語法（排除）
2、代碼是否存在不合理語法（不確定）
3、根據(jù)情況來看，IIS進(jìn)程占用率升高時，SQL占用率同時升高，應(yīng)為SQL數(shù)據(jù)庫的站點(diǎn)，根據(jù)現(xiàn)象判斷，庫或表應(yīng)該正常，估計(jì)是數(shù)據(jù)方面可能有誤；（不確定）
4、服務(wù)器端除了基本的系統(tǒng)服務(wù)，防殺毒及網(wǎng)站運(yùn)作必備服務(wù)之外，并無多余第三方軟件，機(jī)率不大（排除）。

經(jīng)過以上分析判斷，將不確定項(xiàng)連起來得出的結(jié)論是：某個采用了SQL數(shù)據(jù)庫的網(wǎng)站網(wǎng)頁代碼存在不合理語法，導(dǎo)致IIS和SQL進(jìn)程CPU占用率過高。

第二階段排查：
確定范圍，接著繼續(xù)把范圍縮小。
由于服務(wù)器上采用SQL數(shù)據(jù)庫的站點(diǎn)并不多，便于建立獨(dú)立進(jìn)程ID來觀察，將所有采用SQL數(shù)據(jù)庫的站點(diǎn)在IIS管理器中分別建立獨(dú)立的應(yīng)用程序池，然后通過CMD界面輸入：iisapp -a 命今查看并記錄下各IIS池的進(jìn)程ID號，通過多次現(xiàn)象重現(xiàn)時的觀察，有個IIS進(jìn)程ID是導(dǎo)致此次問題的罪魁禍?zhǔn)住?

補(bǔ)充：
限制sql的內(nèi)存。企業(yè)管理器——SQL的屬性（一般是local）——“內(nèi)存”標(biāo)簽，在這里看內(nèi)存的設(shè)置，把最大值改成100M吧（這個確實(shí)有一定的作用）。只不過還是存在系統(tǒng)資源占用比較多的，繼續(xù)尋找產(chǎn)生的原因。。。