2017-01-28 125 views
3

我正在使用EF 6.x來處理我的Azure SDL數據庫的ASP.NET MVC應用程序。最近,隨着負載的增加,應用程序在無法與SQL服務器通信時開始進入狀態。我可以看到有使用exec sp_who到我的數據庫100個活動連接任何新的連接無法與以下錯誤創建:ADO.NET池連接無法重用

System.Data.Entity.Core.EntityException: The underlying provider failed on Open. ---> System.InvalidOperationException: Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because of all pooled connections were in use and max pool size was reached.

大多數時候應用程式的運作從10至20的平均活動連接數。而且任何負載都不會改變這個數字......當負載很高時它會停留在10-20級的事件。但是在某些情況下,如果沒有任何加速時間,它可能會在不到一分鐘的時間內達到100,並且這會在所有請求都失敗時導致應用程序狀態。所有這100個連接都在sleeping狀態和awaiting command

好的部分是我找到了一種解決方法,它幫助我緩解了這個問題 - 從客戶端清除了連接池。我正在使用SqlCoonection.ClearAllPools(),它立即關閉所有連接,然後sp_who顯示我以後的常規10-20連接。

不好的部分,我還不知道根本原因。

只是爲了澄清應用負荷爲200-300併發用戶,其產生每分鐘

1000請求與偉大的建議@DavidBrowne跟蹤一個簡單的模式,我能夠找到泄漏的連接,同時配置Owin泄露連接發動機

private void ConfigureOAuthTokenGeneration(IAppBuilder app) 
{ 
    // here in create method I'm creating also a connection leak tracker 
    app.CreatePerOwinContext(() => MyCoolDb.Create()); 
    ... 
} 
每個請求

基本上,Owin創建一個連接並不會讓它去當WebAPI負荷增加我的煩惱。

難道它是真正的原因嗎?我Owin足夠聰明,以便在需要時(使用所提供的功能)懶惰地創建連接,並讓它在使用時釋放?

+0

你確定你正在配置上下文嗎? –

+0

是的,所有連接都是使用()作用域創建的。而且,相同的加載應用程序可以工作幾天,甚至幾周,然後突然進入故障狀態。 –

+0

你是否排除了數據庫中的普通瓶頸,鎖定升級等等。它可能是一個等待資源的請求隊列,這是一個長時間運行的進程佔用的資源嗎?在您看到的連接堆積期間,是否有任何索引重建或其他維護工作正在進行? –

回答

1

這是非常不可能這是由您的應用程序代碼泄漏連接以外的任何其他引起的。

下面是一個幫助程序庫,可用於跟蹤連接何時泄漏,並報告最初打開連接的呼叫站點。

http://ssbwcf.codeplex.com/SourceControl/latest#SsbTransportChannel/SqlConnectionLifetimeTracker.cs

+0

這是一個很好的建議,用這種幫助找到連接泄漏。我一定會嘗試。 –

+0

我已更新我的問題,我檢測到一個可能是原因的連接泄漏。儘管繼續我的研究 –