IIS是微軟開發(fā)的Web服務(wù)器軟件，被廣泛用于Windows平臺上的網(wǎng)站托管。在使用IIS過程中，可能會遇到應(yīng)用程序池崩潰的問題，原因可能有很多，包括代碼錯誤、資源不足、進程沖突等。本文將為大家介紹IIS應(yīng)用程序池崩潰的問題分析和解決方案。如果您在IIS的Events日志下觀察到以下任一事件，那么本文適合您。

遇到這個問題是我在升級項目版本的時候，升級后的版本網(wǎng)頁功能雖然可以正常使用，但每隔幾分鐘程序池就會忽然崩潰，導(dǎo)致訪問503報錯，我登陸IIS管理器查看，該應(yīng)用掛載的應(yīng)用池狀態(tài)自動變?yōu)榱薙topped。

一、確認(rèn)程序池崩潰原因

a) 滿足下面兩個特征的IIS程序池崩潰是本文可以解決的，其崩潰原因是應(yīng)用程序內(nèi)部反復(fù)報錯，一般是短時間超過五次，導(dǎo)致IIS自動關(guān)閉程序池。
b) 如果不滿足這兩個條件，那就不是程序報錯導(dǎo)致的，后面的內(nèi)容也就不用看了。

1、應(yīng)用池崩潰后，網(wǎng)頁訪問提示503。

2、查看IIS的Events里有無錯誤。

通常報錯為：

A process serving application pool ‘Classic .NET AppPool’ suffered a fatal communication error with the Windows Process Activation Service. The process id was ‘3328’. The data field contains the error number.

我在Server Manager>IIS>Events下查看，這里是有報錯的。

二、查找問題來源并修復(fù)

1、下載 DebugDiag 插件

這里我們下載一個插件 Debug Diagnostic Tool (點擊此處跳轉(zhuǎn)下載頁面)，通過這個插件，我們可以在IIS的錯誤事件發(fā)生時捕獲更加詳細(xì)，應(yīng)用級別的日志。

點擊download下載，選擇32還是64位，下載msi鏡像，下載成功之后安裝。

2、配置 DebugDiag 的斷點信息

安裝成功之后我們打開安裝好的 DebugDiag 2 Analysis 程序，按照下面步驟添加斷點。

選擇“crash (崩潰)”規(guī)則。

選擇“A specific IIS web application pool (特定 IIS Web 應(yīng)用程序池)”

選擇崩潰的特定應(yīng)用程序池。

選擇“Breakpoint (斷點)”

點擊“添加斷點”

單擊 Breakpoint 下的“Ntdll!ZwTerminateProcess”，將其選為 Breakpoint Expression。將 Action Type 更改為“Full userdump”并將 Action Limit 設(shè)置為 10，然后單擊 OK。

點擊保存并關(guān)閉。
點擊下一步以激活斷點。

點擊“Next”，配置日志路徑

單擊“Finish”以激活規(guī)則。

您現(xiàn)在會看到崩潰規(guī)則處于活動狀態(tài)并且“Userdump Count”為0。一旦問題發(fā)生，轉(zhuǎn)儲計數(shù)就會增加，并會生成相應(yīng)的轉(zhuǎn)儲文件。

3、復(fù)現(xiàn)崩潰場景，查看問題日志

我們復(fù)現(xiàn)了出現(xiàn)問題的場景，IIS應(yīng)用池再次崩潰，網(wǎng)頁503無法訪問，DebugDiag Tool的“Userdump Count”變?yōu)榱?0，表示程序池崩潰前程序已經(jīng)出錯了10次。

我們根據(jù)剛剛配置的日志路徑，找到對應(yīng)這個問題應(yīng)用池的日志文件。

打開日志文件，我們看到了應(yīng)用運行中的種種報錯，找到反復(fù)高頻報錯的點，然后修復(fù)即可。

我這里有兩個異常，一個是Ibatis映射的對象屬性沒有對上，導(dǎo)致的工廠加載時報錯。另一個是空指針異常，因為有個全局變量在全局線程里反復(fù)調(diào)用，但配置文件里忘記配置了。兩個都是因為粗心導(dǎo)致的烏龍問題 = =。

到此這篇關(guān)于IIS應(yīng)用程序池崩潰的解決方案的文章就介紹到這了,更多相關(guān)IIS應(yīng)用程序池崩潰內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論