Timeout di connessione frequente di SQL di Azure

Question

Stiamo eseguendo un'app Web (2 istanze) su Azure, supportata da un database SQL Azure. In qualsiasi momento ci sono 50-150 utenti che usano il sito web. Il database viene eseguito a livello di prestazioni S2. Il DTU è in media del 20% circa.

Tuttavia, un paio di volte ogni giorno improvvisamente ricevo centinaia di errori nei miei log con timeout, come questo:

Si è verificato un errore durante l'esecuzione della definizione del comando. Vedi l'eccezione interna per i dettagli.

L'operazione di attesa è scaduta.

Timeout scaduto. Il periodo di timeout è trascorso prima del completamento dell'operazione o il server non risponde. Questo errore si è verificato durante il tentativo di connessione alla destinazione di routing. La durata spesa durante il tentativo di connessione al server originale era - [Pre-Login] initialization = 1; handshake = 21; [Login] inizializzazione = 0; Autenticazione = 0; [Post-Login] completo = 1;

Stiamo utilizzando EF6 per le query con il timeout del comando predefinito. Ho configurato questa strategia di esecuzione:

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

Il database (circa 15 GB totali) è fortemente indicizzato. Questi errori si verificano dappertutto, di solito dozzine a centinaia nell'arco di 1-2 minuti.

Quali operazioni posso intraprendere per evitare che ciò accada?

Answer 1

Il fatto che avvenga in 1-2 minuti potrebbe significare un'attività esplosiva o un processo che potrebbe bloccare le tabelle.

Se il DTU durante quei tempi è al 20% non è un problema di CPU, ma si può sempre trovare quali sono i colli di bottiglia eseguendo questa ricerca 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 

Anche se il DB è fortemente indicizzati, gli indici vengono frammentati, mi piacerebbe consiglio di eseguire questo per verificare l'attuale frammentazione:

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 

È anche possibile utilizzare l'automazione Azure per fissare un ricostruzione automatica degli indici frammentati, vedi risposta a: Why my Azure SQL Database indexes are still fragmented?

012.351.641.061.