Częstotliwości połączeń z częstym łączem SQL Azure

Question

Używamy aplikacji internetowej (2 wystąpienia) na platformie Azure, wspieranej przez bazę danych SQL Azure. W dowolnym momencie 50-150 użytkowników korzysta ze strony internetowej. Baza danych działa na poziomie wydajności S2. DTU wynosi średnio około 20%.

Jednak kilka razy dziennie nagle dostać setki błędów w moich dziennikach z limity czasu coś takiego:

Wystąpił błąd podczas wykonywania definicji poleceń. Zobacz wewnętrzny wyjątek, aby poznać szczegóły.

Przekroczono limit czasu oczekiwania.

Limit czasu wygasł. Okres oczekiwania upłynął przed zakończeniem operacji lub serwer nie odpowiada. To niepowodzenie wystąpiło podczas próby połączenia z miejscem docelowym routingu. Czas spędzony podczas próby połączenia z pierwotnym serwerem to - [Pre-Login] initialization = 1; handshake = 21; [Logowanie] inicjalizacja = 0; authentication = 0; [Po zalogowaniu] complete = 1;

Używamy EF6 do zapytań z domyślnym czasem oczekiwania na polecenia. Skonfigurowałem tę strategię wykonywania:

SetExecutionStrategy("System.Data.SqlClient", 
      () => new SqlAzureExecutionStrategy(10, TimeSpan.FromSeconds(15))); 

Baza danych (łącznie około 15 GB) jest silnie indeksowana. Błędy te występują wszędzie, zwykle od dziesiątek do setek w ciągu 1-2 minut.

Co mogę zrobić, aby temu zapobiec?

Answer 1

Fakt, że zdarza się to w ciągu 1-2 minut, może oznaczać wybuch aktywności lub proces, który może blokować tabele.

Jeśli DTU w tamtych czasach jest na poziomie 20% nie jest to kwestia procesora, ale zawsze można znaleźć, które są wąskie gardła przez uruchomienie tej kwerendy na DB:

SELECT TOP 10 
total_worker_time/execution_count AS Avg_CPU_Time 
     ,execution_count 
     ,total_elapsed_time/execution_count as AVG_Run_Time 
     ,(SELECT 
       SUBSTRING(text,statement_start_offset/2,(CASE 
                  WHEN statement_end_offset = -1 THEN LEN(CONVERT(nvarchar(max), text)) * 2 
                  ELSE statement_end_offset 
                 END -statement_start_offset)/2 
         ) FROM sys.dm_exec_sql_text(sql_handle) 
     ) AS query_text 
FROM sys.dm_exec_query_stats 
ORDER BY Avg_CPU_Time DESC 

Nawet jeśli DB jest mocno indeksowane, indeksy uzyskać rozdrobniony, będę rada działa to w celu sprawdzenia obecnego rozdrobnienia:

select a.*,b.AverageFragmentation from 
(    SELECT tbl.name AS [Table_Name], tbl.object_id, i.name AS [Name], i.index_id, CAST(CASE i.index_id WHEN 1 THEN 1 ELSE 0 END AS bit) AS [IsClustered], 
CAST(case when i.type=3 then 1 else 0 end AS bit) AS [IsXmlIndex], CAST(case when i.type=4 then 1 else 0 end AS bit) AS [IsSpatialIndex] 
       FROM 
       sys.tables AS tbl 
       INNER JOIN sys.indexes AS i ON (i.index_id > 0 and i.is_hypothetical = 0) AND (i.object_id=tbl.object_id))a 
inner join 
(    SELECT tbl.object_id, i.index_id, fi.avg_fragmentation_in_percent AS [AverageFragmentation] 
       FROM 
       sys.tables AS tbl 
       INNER JOIN sys.indexes AS i ON (i.index_id > 0 and i.is_hypothetical = 0) AND (i.object_id=tbl.object_id) 
       INNER JOIN sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'LIMITED') AS fi ON fi.object_id=CAST(i.object_id AS int) AND fi.index_id=CAST(i.index_id AS int) 
)b 
on a.object_id=b.object_id and a.index_id=b.index_id 
order by AverageFragmentation desc 

można również użyć Azure Automation, aby zaplanować automatyczne odbudowy indeksy rozdrobnionych, patrz odpowiedź na: Why my Azure SQL Database indexes are still fragmented?