Problemy z łącznością z bazą danych Azure SQL - Zbyt wiele połączeń?

Question

Mam witrynę, która jest białą etykietą (wiele wersji tej samej witryny), którą niedawno uruchomiłem. Nie ma jeszcze dużego ruchu - głównie boty, ale prawdopodobnie 800 użytkowników dziennie. Jest on hostowany na platformie Azure z bazą danych Azure oraz panelem administracyjnym znajdującym się na nie-lazurowym serwerze. Obie witryny łączą się z tą samą bazą danych Azure. Istnieje również kilka ról pracowniczych do przetwarzania danych - w 99% przypadków nic nie robią, ale sprawdzają regularnie.

zawsze doświadczył przypadkowe błędy, które trwają kilka sekund, a następnie jest ponownie ok, takie jak:

A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)

Tego ranka jednak mieliśmy bardziej poważny problem. Zaczęło się:

System.ComponentModel.Win32Exception: An existing connection was forcibly closed by the remote host

Nastąpiło to podczas botów (Google, Baidu, AhrefsBot & Wiseguys.nl) indeksowania witryny. Dostałem z nich jeden lub więcej błędów. Dostałem:

System.Data.SqlClient.SqlException: The service has encountered an error processing your request. Please try again. Error code 40143. A severe error occurred on the current command. The results, if any, should be discarded.

To było podczas fazy ExecuteReader.

10 minut później pojawił się prawdziwy problem - co oznaczało, że nikt nie mógł zalogować się do interfejsu administratora, ale witryna hostowana na platformie Azure wyglądała dobrze, gdy testowałem, mimo że boty wciąż wywoływały błędy. Problemem było:

System.ComponentModel.Win32Exception: The wait operation timed out

Trwało to z przypadkowych połączeń działa z przerwami przez około godzinę. Potem uderzyłem w inny problem:

System.Data.SqlClient.SqlException: Resource ID : 1. The request limit for the database is 180 and has been reached. See ' http://go.microsoft.com/fwlink/?LinkId=267637 ' for assistance.

To zdarzenie miało miejsce w ostatniej godzinie - głównie dla ról pracowników. Potem próbował dowiedzieć się, co było objęcie wszystkich tych wniosków i znalazłem to polecenie:

SELECT * FROM sys.dm_exec_requests

To tylko powróciło 1 lub 2 żądań kiedy biegałam w kółko.

Moje pytania brzmią: 1) Czy ktoś inny doświadcza względnie regularnego (raz, może dwa razy dziennie) tymczasowego rozłączenia się z serwerem hostowanym na platformie Azure? 2) Czy powyższa lista zdarzeń wskazuje na konkretny problem? Wszystko mogło się zdarzyć, gdy wielu administratorów logowało się jednocześnie. 3) Jak mogę lepiej debugować liczbę żądań do bazy danych, gdy otrzymam komunikat o limicie 180?

Z góry dziękuję.

Answer 1

Napisałem to pytanie kilka lat temu i otrzymałem powiadomienie o niewielkiej zmianie w tytule. Po zapoznaniu się z większą ilością baz danych SQL Azure, znam teraz odpowiedź na ten problem. Z korzyścią dla innych, po prostu twoja baza danych jest ustawiona na poziom, który jest zbyt niski.

Azure ma poziomy cenowe, które mają dość znaczne różnice w wydajności. Aby to osiągnąć, dławią one wiele wskaźników wydajności, np. Moc procesora, żądania na minutę, itd.

Oznacza to, że jeśli przesuniesz swój poziom, twoje żądania zaczną dostawać się do kolejki, ponieważ moc procesora/objętość żądań jest za wysoka do przetworzenia. Powoduje to przekroczenie limitu czasu, a następnie ograniczenie żądania wzrasta, gdy żądania czekają na przetworzenie. W końcu dochodzi do punktu, w którym baza danych zasadniczo spada.

Moje doświadczenie jest takie, że niższe poziomy baz danych, takie jak S0 i S1, są w rzeczywistości zbyt słabe i nie powinny być używane do niczego innego, niż do programowania lub bardzo podstawowych witryn.

W portalu Azure dostępnych jest kilka świetnych narzędzi umożliwiających debugowanie zawartości bazy danych, takich jak wykresy procesora, doradca indeksu i statystyki skuteczności zapytań.

Answer 2

Brzmi to tak, jakbyś był na dobrej drodze, patrząc na to dm_exec_requests DMV. Podejrzewam, że już to zauważyłeś, ale jest sporo więcej informacji na temat limitu 180 przepustnicy, który jest documented here i nakreśla niektóre kluczowe powody.

Jeśli jest to interesujące, mamy usługę o nazwie Cotega, która może być pomocna w przypadku obu pytań. Po pierwsze, możemy uruchomić cały klucz DMV's against your database, aby pokazać, co się dzieje, aby pomóc w analizie bazy danych, a my możemy również powiadomić Cię (e-mail, sms), gdy zaczniesz zbliżać się do swojej throttling limits.

Answer 3

A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)

i

System.ComponentModel.Win32Exception: An existing connection was forcibly closed by the remote host

może zarówno być bezpiecznie zignorować. Występują, gdy połączenie zostaje przerwane na zewnątrz, co może się zdarzyć, jeśli użytkownik zamknie przeglądarkę w trakcie otrzymywania odpowiedzi lub gdy inne problemy sieciowe przerwie połączenie. Istnieją inne podobne wyjątki prawdopodobnie ze względu na aktywny inny kod framework, gdy ten warunek zostanie wykryty. Te wyjątki są generowane, aby przerwać przetwarzanie żądania, ponieważ i tak rozmówca już nie słucha.

Jeśli chcesz śledzić liczbę aktywnych żądań, powinieneś utworzyć wrapper, którego używasz do wszystkich połączeń SQL, robić sprzężony przyrost i ubytek, gdy połączenie jest w użyciu (użyj IDisposable) i śledzić znak wysokiej wody dla tej wartości. Możesz zgłosić to na specjalnej stronie ukrytej lub administracyjnej. W ten sposób, nawet jeśli nie możesz dostać się do systemu, gdy wystąpi problem, możesz zobaczyć, jaka jest najwyższa liczba aktywnych połączeń, aby upewnić się, że nie był to twój problem. Może to również pomóc w wykryciu, jeśli nie pozbywasz się wszystkich połączeń.