2013-09-25 31 views
4

我們正在嘗試診斷上週在我們的生產環境中發生的問題。長話短說,即使在重新啓動應用程序池和IIS之後,數據庫連接池似乎也充滿了來自我們的ASP.NET 3.5應用程序的活動連接,這些連接不會清除。在Application_Start&Application_End中調用SqlConnection.ClearAllPools()?

高級DBA表示,由於網絡連接發生在操作系統級別,回收應用程序和IIS並沒有切斷實際的網絡連接,所以SQL Server使數據庫連接繼續運行,而我們的應用程序仍然無法運行到達數據庫。

在仰視的方式來強制數據庫連接池復位,我發現靜態方法SqlConnection.ClearAllPools(),與文件,說明它做什麼,但幾乎沒有什麼解釋調用它。好像在Application_Start開始時調用它,在我的global.asax.cs中結束Application_End是一個很好的安全措施來保護應用程序免受中毒連接池的影響,儘管它當然會在啓動/關閉時間中產生性能影響。

正是我所描述的良好做法?有更好的嗎?我們的目標是允許簡單的應用程序重新啓動來重置應用程序的受損連接池,而無需重新啓動操作系統或SQL Server服務,這會影響許多其他應用程序。

任何指導,非常感謝。

回答

2

當一個進程死亡時,所有網絡連接總是始終總是立即關閉。這是在TCP層面。與ADO.NET無關並適用於所有應用程序。殺死瀏覽器,並停止所有下載。殺死FTP客戶端並立即關閉所有連接。

此外,連接池是每個進程。因此,啓動應用程序時清除它是無用的,因爲池是空的。在關閉時清除它並不是必需的,因爲所有連接都將隨時(正常)關閉。

很可能,您的應用沒有返回連接池。您必須在所有情況下處理所有連接後使用。如果你不這樣做,懸掛的連接將積累無限期的時間。

清除池不會釋放懸掛連接,因爲這些連接似乎正在使用中。 ADO.NET如何告訴你永遠不會再使用它們?它不能。

看看sys.dm_exec_connections看誰打開連接。您可能會將ADO.NET池大小增加爲停止標準。 SQL Server每個實例可以接管30多個連接。你通常永遠不會飽和。

+0

謝謝。我應該提到我100%確定我正在使用using()語句包裝每個數據庫調用,以確保即使我的應用程序崩潰,也會調用Dispose(),並且在我完成它們的任何時刻都會明確地關閉連接。 您描述的內容對我來說很有意義,但DBA讓我相信其中的一些內容是在操作系統級別進行管理的,而不是過程。我們有100個連接在IIS的回收過程中生存下來,所以也許是我們根本沒有懷疑的其他應用程序。嗯。 。 。 。 –

+0

你看到了什麼樣的錯誤和其他症狀? – usr

+1

您可以將「App Name」參數添加到連接字符串中,以跟蹤與DMV連接的人員。你也可以在那裏看到客戶的PID和其他細節。 – usr

相關問題