Co powoduje "Błędy krytyczne połączenia wewnętrznego"

Question

Mam wiele witryn ASP.Net (.Net v3.5) działających na serwerze z zapleczem bazy danych SQL 2000. Przez kilka miesięcy otrzymywałem pozornie InvalidOperationExceptions z komunikatem "Błąd krytyczny połączenia wewnętrznego". Czasami jest kilka dni pośrednich, podczas gdy w innych przypadkach występuje wiele błędów dziennie.

Wyjątek nie ogranicza się tylko do jednej witryny, ale mają one wspólne zestawy danych biznesowych i dostępu do danych. Błąd wydaje się być zawsze wyrzucany z SqlClient.TdsParser.Run(). Czasami jest on wyrzucany ze starych klasycznych wywołań SqlCommand.Execute(), a czasami jest wyrzucany z kodu Linq2Sql.

Zostałem zapewniony przez użytkowników sieci, że nie ma błędów lub pakietów utraconych po ich zakończeniu. Czy ktoś inny tego doświadczył? Czy to może być problem ze sterownikiem? Nie byliśmy jeszcze w stanie określić konkretnego warunku dla tego wyjątku.

Biegniemy II6 w systemie Windows Server 2003.

Answer 1

Po kilku miesiącach ignorowania tego problemu, zaczęło ono osiągać masę krytyczną wraz ze wzrostem natężenia ruchu. Pod dużym obciążeniem, w tym niektórymi gąsienicami, szalały rzeczy, a te błędy lały się bez przerwy.

Dzięki próbom i błędom ostatecznie znaleźliśmy garść zapytań SqlCommand lub LINQ, których SqlConnection nie zostało zamknięte natychmiast po użyciu. Zamiast tego, poprzez pewne niechlujne programowanie pochodzące z nieporozumień połączeń LINQ, obiekty DataContext zostały utylizowane (i połączenia zamknięte) tylko na końcu żądania, a nie natychmiast.

Po refaktoryzacji tych metod, aby natychmiast zamknąć połączenie z blokiem C# "using" (zwalniając tę ​​pulę dla następnego żądania), nie otrzymaliśmy więcej błędów. Chociaż nadal nie wiemy, z jakiego powodu pula połączeń byłaby tak pomieszana, byliśmy w stanie przerwać wszystkie tego typu błędy. Ten problem został rozwiązany w związku z innym podobnym błędem, który napisałem, znalezionym tutaj: Why is my SqlCommand returning a string when it should be an int?

Answer 2

Sprawdź folderu dziennika swojego serwera (\ Program Files \ Microsoft SQL Server \ MSSQL.1 \ MSSQL \ Log lub podobny) dla plików nazwanych SqlDump * .mdmp i SqlDump * .txt. Jeśli znajdziesz jakiś, musisz go zabrać do działu wsparcia produktu.

Answer 3

Wygląda na to, że połączenie z bazą danych zostało przerwane lub przekroczono limit czasu.

Niedawno mieliśmy podobne problemy, przenosząc się do IIS 6 z IIS 5 łączącego się z SQL 2000. Nasz problem został rozwiązany przez zwiększenie liczby dostępnych efemerycznych portów.

Sprawdź wykorzystanie efemerycznych portów przez serwer IIS. Domyślne maks. Nie. Liczba dostępnych portów wynosi zwykle 4000. Można rozważyć zwiększenie tej wartości, jeśli witryny na serwerze są szczególnie obciążone lub aplikacja wykonuje wiele wywołań bazy danych.

Możesz je najpierw monitorować, aby sprawdzić, czy przekroczył maksymalny limit.

Wyszukaj w bazie wiedzy Microsoft "MaxUserPort" i "TcpTimedWaitDelay" i wprowadź niezbędne zmiany w rejestrze. Przed wprowadzeniem zmian należy wykonać kopię zapasową rejestru lub migawki serwera. Będzie trzeba ponownie uruchomić, aby zmiany zaczęły obowiązywać.

Powinieneś dokładnie sprawdzić swoją bazę danych, a połączenie zestawu rekordów jest zamykane po użyciu. Brak zamknięcia spowoduje niepotrzebne wykorzystanie tego zakresu portów.

Sprawdź skuteczność procedur przechowywanych, ponieważ mogą one zająć więcej czasu niż potrzebują.

"Jeśli szybko otworzysz i zamkniesz 4000 gniazd w mniej niż cztery minuty, osiągniesz domyślne maksymalne ustawienie dla anonimowych portów klienta, a nowe próby połączenia z gniazdem nie będą działać, dopóki nie upłynie limit czasu dla istniejących zestawów gniazd TIME_WAIT." - od http://support.microsoft.com/kb/328476