2011-01-12 162 views
1

我們最近推出了一個新的網站......在高峯時段有大約150個用戶活躍。在繁忙時段,我們每隔幾分鐘就會遇到一個問題,下面列出了例外情況。SQL Server連接問題

System.Web.HttpUnhandledException: 
Exception of type 'System.Web.HttpUnhandledException' was thrown. 
---> System.Data.SqlClient.SqlException: The client was unable to establish a connection because of an error during connection initialization process before login. 
Possible causes include the following: 
    the client tried to connect to an unsupported version of SQL Server; 
    the server was too busy to accept new connections; 
    or there was a resource limitation (insufficient memory or maximum allowed connections) on the server. (provider: Named Pipes Provider, error: 0 - No process is on the other end of the pipe.) 

我們的數據訪問層使用以下語法調用各種DataTableAdapter。

編輯

是,da是分配給DataTableAdapter名稱。沒有connection.Open(),因爲DataTableAdapter處理所有這些,對嗎?

using(TheDataLayer.some.strongly.typedNameTableAdapters.suchAndSuchTableAdapter da = new TheDataLayer.some.strongly.typedNameTableAdapters.suchAndSuchTableAdapter()) 
     { 
      StronglyTyped.DataTable dt = new StronglyTyped.DataTable(); 
      da.FillByVariousArguments(dt, ..., ...); 
      //da.Dispose(); 

      return something; 
     } 

連接字符串看起來像:

<add name="MyConnectionString" 
     connectionString="Data Source=myDBServerName;Initial Catalog=MyDB;User ID=MyUserName;Password=MyPassword" 
     providerName="System.Data.SqlClient" /> 

我試圖排除在代碼是問題。有什麼「簡單的」可以做到儘量減少這個問題?

感謝。

+3

如果你正在使用'using'語句,爲什麼你在裏面調用'Dispose()'? –

+1

您將不得不向我們展示您的'conn.Open'發生的代碼。目前我們沒有看到;這就是問題所在。 –

+0

是的,我明白.Dispose()不是必要的和多餘的,但這不會是這個問題的原因,是嗎?我試圖在謹慎的一面犯錯。現在忽略該行〜 – Robert

回答

4

您是否在連接字符串設置中直接嘗試了「連接池」?

例子:

connectionString="....;Pooling=true;Min Pool Size=1;Max Pool Size=10;..." 

你可以在這裏閱讀更多的信息:http://msdn.microsoft.com/en-us/library/8xx3tyca%28v=vs.71%29.aspx

+0

我覺得這可能是朝着正確方向邁出的一步。沒有指定最大池大小,它默認爲100?這看起來不錯,但是我會在下一次投入生產時將其升至500或1000,並看看它是否會產生重大差異。 – Robert

1

沒有看到實際打開並使用該連接的代碼,這是很難說問題出在哪裏。

請更新您的問題與創建DataAdapter時發生的情況(我猜這就是da的含義)。

另外,如果您使用的是using聲明,則不應該爲您創建的聲明創建using聲明。

0

也許與您遇到的實際問題無關,但如果您嘗試連接時未指定正確的端口以及數據庫服務器名稱,則也會引發此錯誤。

+0

我可以看到,這是您對問題的第一個答案,因此您沒有代表將此發佈爲評論,但將來可能需要考慮將其作爲評論發佈。答案應該是解決問題的方法,你很有信心可以解決問題。 – Fluffeh

1

我們有類似的問題,只在我們的生產環境中發生,而且與負載特別相關。在一天的繁忙時段,我們會收到上述例外情況。

我們經歷了一場大規模調查,探討爲什麼會發生這種異常,並做了很多修改來解決問題。我們所做的事實上的變化解決了問題,因爲連接池設置通過將最小池大小設置爲1並將最大池大小設置爲10.(它可以根據您的情況而有所不同)

當您有幾個即客戶數據庫的1000年,並使用默認連接字符串(即數據庫= DBName;服務器= ServerName)。我們沒有明確地設置最小/最大池大小,因此它採用了將最小池大小設置爲0並將最大池大小設置爲100的默認設置。

再一次,我沒有具體的證據,但理論是,在基於負載的一天的繁忙時間,它與DB服務器進行了多次連接,DB服務器被單點連接請求轟炸到多個數據庫。無論是應用程序服務器還是數據庫服務器都有足夠的帶寬來在短時間內處理多個連接。另外,它與大多數數據庫的服務器一起發生。雖然我們一次沒有看到很多連接,但是應用程序服務器無法連接到數據庫很短的時間,因爲它有大量的請求進入。

當我們設置最小池大小後,我們仍然存在這個問題因爲每個數據庫至少有一個連接可用,並且如果需要連接到多個數據庫的請求爆炸,我們在請求新數據庫之前已經有至少一個可用的數據庫連接。