2016-03-17 15 views
7

Wir betreiben eine Webanwendung (2 Instanzen) auf Azure, die von einer SQL Azure-Datenbank unterstützt wird. Zu jeder Zeit nutzen 50-150 Benutzer die Website. Die Datenbank wird auf der Ebene S2 ausgeführt. Die DTU liegt durchschnittlich bei 20%.Azure SQL häufige Verbindungstimeouts

jedoch ein paar Mal jeden Tag, als ich plötzlich hunderte von Fehlern in meinem Logs mit Timeouts, wie diese:

ist ein Fehler aufgetreten, während der Befehlsdefinition ausgeführt wird. Weitere Informationen finden Sie in der inneren Ausnahme.

Die Wartezeit ist abgelaufen.

Timeout abgelaufen. Das Zeitlimit ist vor dem Abschluss des Vorgangs abgelaufen oder der Server reagiert nicht. Dieser Fehler ist beim Versuch aufgetreten, eine Verbindung zum Routingziel herzustellen. Die Dauer beim Versuch, eine Verbindung zum ursprünglichen Server herzustellen, war - [Pre-Login] initialization = 1; Handschlag = 21; [Login] Initialisierung = 0; Authentifizierung = 0; [Post-Login] abgeschlossen = 1;

Wir verwenden EF6 für Abfragen mit dem Standardbefehlszeitlimit. Ich habe diese Ausführungsstrategie konfiguriert:

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

Die Datenbank (ca. 15 GB insgesamt) ist stark indiziert. Diese Fehler treten überall auf, normalerweise innerhalb von 1-2 Minuten von Dutzenden bis zu Hunderten.

Welche Schritte kann ich unternehmen, um dies zu verhindern?

+0

Sind der App Service und die SQL-Datenbank im selben Datencenter? –

+0

Ja, sie sind in der gleichen Region. – Knelis

Antwort

8

Die Tatsache, dass es in 1-2 Minuten passiert, könnte einen Burst in Aktivität oder einen Prozess bedeuten, der Tabellen sperren könnte.

Wenn Ihr DTU während dieser Zeit bei 20% ist keine CPU Problem, aber man kann immer finden, welche die Engpässe, indem Sie diese Abfrage auf der DB sind:

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 

Auch wenn die DB stark ist indiziert, Indizes erhalten fragmentiert, würde ich Beratung läuft dies die aktuelle Fragmentierung zu überprüfen:

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 

Sie können auch Azure Automation verwenden einen automatischen Wiederaufbau der fragmentierten Indizes zu planen, siehe Antwort auf: Why my Azure SQL Database indexes are still fragmented?

+0

Danke für Ihre Antwort. Ich habe jetzt ein Azure Automation-Runbook konfiguriert, um die Indizes jede Nacht mithilfe der Wartungslösung von Ola Hallengren zu optimieren. Inzwischen habe ich auch die Datenbank auf S3 aktualisiert und seit ich das gemacht habe, gab es keine Fehler. Es sieht in der Tat wie ein Leistungsproblem aus. Einige der größten Tische waren sehr fragmentiert, also denke ich, dass Sie genau richtig waren. – Knelis