2015-11-02 104 views
2

我們有一個新的ASP.NET網站在一對負載平衡的Azure虛擬機上運行。該網站非常簡單,並使用Kentico CMS。自上線後24小時內兩次,兩臺Web服務器上的應用程序池突然停止(相距5-10分鐘),導致出現503: Service unavailable錯誤。IIS應用程序池在Azure負載平衡虛擬機上崩潰

瞭解Windows系統日誌我看到這導致問題的錯誤:

應用程序池「[NAME]」被自動由於在這個過程中 一系列的失敗(ES)禁用提供該應用程序池。

領導到這是一系列的警告:

服務應用程序池的處理「[[NAME]遇到致命的 通信錯誤與Windows進程激活服務。進程ID爲 爲'[[PROCESS ID]]'。數據字段包含錯誤號碼 。

顯然,這是IIS在踢快速失敗保護。什麼是不明確的是如何找到這個「致命通信錯誤」的原因。

經過一些網絡搜索後,我已經安裝了調試診斷工具,它幫助我識別出在任何情況下相關進程都是IIS工作進程(w3wp.exe)。這個工具對我來說是新的,但不幸的是,自從我安裝它以來發生問題的唯一時間,沒有生成垃圾箱。然而,它的日誌中含有大量的消息是這樣的:

第一次機會異常 - 0xe0434352造成線程系統ID: [ID]

令人沮喪的事情是,我不不知道要採取哪些步驟來複制錯誤條件。即使在負載測試下,它也不會出現在非常相似的環境中。以下是關於我的設置的一些事實:

  • ASP.NET版本=與身份設置爲域帳戶上的網站目錄
  • 應用設置,最大一個修改權限運行4.5.2
  • 應用程序池工作進程

任何意見非常讚賞。

*更新1 *

我現在有DebugDiag資料轉儲由 「致命的通信錯誤」 警告事件發生。轉儲總結如下:

Dump Summary 
------------ 
Process Name: w3wp.exe : C:\Windows\SysWOW64\inetsrv\w3wp.exe 
Process Architecture: x86 
Exception Code: 0xC00000FD 
Exception Information: The thread used up its stack. 
Heap Information: Present 
+0

如果有任何記錄錯誤,您可以檢查Kentico事件日誌嗎? –

+0

Kentico的事件日誌中唯一的錯誤是由自定義Web部件中的Response.Redirect導致的「線程被中止」異常。將此方法的重載的endResponse參數設置爲false會停止它拋出異常。上述主要錯誤並沒有重新發生,因爲這是固定的,但「致命的通信錯誤」警告已經提出了幾次,所以我認爲這不是原因。 – getsetcode

回答

3

在我的跟蹤,這歸因於錯誤結束我的代碼。在非常邊緣的情況下,CMS返回一個空的Guid而不是實際的ID,導致遞歸方法中的堆棧溢出。

我上面發佈的0xC00000FD異常代碼實際上是一個堆棧溢出異常,所以一旦我知道並下載了Debug Diagnostcs轉儲文件,我就能夠在本地複製崩潰場景。順便說一句,這個工具非常強大,並且能夠證明崩潰的確切條件。

我可以對那些到達這裏有類似問題的人說 - 首先,不要認爲問題不在您的代碼中!其次,使用調試診斷程序。

2

首先,什麼是你的應用程序池定期回收的時間間隔設置&在IIS重疊設置? - 如果在計劃回收並禁用重疊時發生這些事件,則會發生此行爲。即使啓用了重疊功能,我也猜測它與應用程序池的自動回收有些關聯,因爲兩個實例在同一時間都受到cca的影響&它每天發生兩次,並且可能導致記錄您提到的警告(Here you might find how to disable logging this warning in case it is caused by automatic recycling

如果走不通,你可以找到有關警告事件在這裏更多的細節: IIS Application Pool Availability

約在調試Diagnostcs工具在這裏: How to use the Debug Diagnostics tool to troubleshoot an IIS process that stops unexpectedly

+0

應用程序池每1740分鐘回收一次,設置爲重疊。不符合問題。正如我所說,它似乎是導致應用程序池快速失敗保護功能的「致命通信錯誤」的常見現象。我現在有由此事件生成的DebugDialog轉儲,因此如果有任何問題,我會報告回來線索。 – getsetcode

相關問題