Perché il mio database SQL di Azure (SQL Server) viene sovraccaricato di dati IO per periodi alla volta? [chiuso]

Sto eseguendo un database SQL di Azure con l'edizione S2 (50 DTU). L'uso normale del server si blocca in genere attorno al 10% di DTU. Tuttavia, questo server entra regolarmente in uno stato in cui invierà l'utilizzo DTU del database all'85-90% per ore. Quindi all'improvviso torna al normale utilizzo del 10%.

Le query sul server dall'applicazione sembrano ancora funzionare rapidamente durante questo stato sovraccarico.

Posso ridimensionare il server da S2 => nulla (ad esempio S3) => S2 e sembra cancellare lo stato in cui è bloccato. Ma dopo alcune ore ripeterà nuovamente lo stesso ciclo di stato sovraccarico. Un'altra cosa strana che ho notato è che se eseguo questo server su un piano S3 (100 DTU) 24/7 non ho osservato questo comportamento. Sembra accadere solo quando ho ridimensionato il database a un piano S2 (50 DTU). Sul piano S3 sono sempre seduto al 5-10% di utilizzo della DTU. Ovviamente sottoutilizzato.

Ho controllato i rapporti sulle query SQL di Azure alla ricerca di query non autorizzate, ma non vedo nulla di insolito e mostra le mie query usando le risorse come mi sarei aspettato.

Come possiamo vedere qui, tuttavia, l'utilizzo proviene da Data IO. Se modifico il rapporto sul rendimento qui per mostrare le query I / O principali di MAX, vediamo questo:

Guardando queste query di lunga durata sembra puntare ad aggiornamenti statistici. Non c'è davvero nulla in esecuzione dalla mia applicazione. Ad esempio, la query 16302 mostra:

SELECT StatMan([SC0], [SC1], [SC2], [SB0000]) FROM (SELECT TOP 100 PERCENT [SC0], [SC1], [SC2], step_direction([SC0]) over (order by NULL) AS [SB0000]  FROM (SELECT [UserId] AS [SC0], [OrganizationId] AS [SC1], [Id] AS [SC2] FROM [dbo].[Cipher] TABLESAMPLE SYSTEM (1.250395e+000 PERCENT) WITH (READUNCOMMITTED) ) AS _MS_UPDSTATS_TBL_HELPER ORDER BY [SC0], [SC1], [SC2], [SB0000] ) AS _MS_UPDSTATS_TBL  OPTION (MAXDOP 16)

Ma ancora una volta, il rapporto mostra anche che queste query utilizzano solo una piccola percentuale dell'utilizzo di I / O dati sul server (<4%). Inoltre eseguo settimanalmente gli aggiornamenti delle statistiche (e le ricostruzioni dell'indice) su tutto il database come parte della sua regolare manutenzione.

Ecco un altro rapporto che mostra le query IO di dati MAX per un periodo di tempo che copre diverse ore solo durante l'incidente con utilizzo di risorse elevate.

Come possiamo vedere, in realtà non ci sono query che segnalano un uso significativo di dati IO.

Ho anche funzionato sp_who2e sp_whoisacivenel database e non vedo davvero nulla che mi salti addosso (anche se ammetterò che non sono un esperto di questi strumenti).

Come faccio a capire cosa sta succedendo qui? Non credo che nessuna delle mie domande sull'applicazione sia responsabile di questo utilizzo delle risorse e ho la sensazione che ci sia un processo interno in esecuzione sul server che lo sta uccidendo.

Dato che durante il picco (s) la tua attività di registro è minima possiamo supporre che non ci sia (o molto) DUI in corso.

Ad un certo punto dici che il picco non influisce sulle prestazioni e ad un altro che lo fa. Cos'è questo?

Dici anche che questo scompare dopo un'operazione di scala. Questo ha senso in quanto analogo a un riavvio on-premise che ucciderà efficacemente tutti i processi ecc.

Presumo correttamente supponendo che si acceda a questo database dal livello applicazione? In tal caso, sospetto che le tue connessioni non vengano chiuse correttamente . Il garbage collector dovrebbe prendersi cura di questi alla fine (che non dovrebbe essere invocato), ma ho visto che questa situazione esatta si verifica a causa di connessioni non chiuse dal livello app. Nel nostro caso, l'applicazione era così occupata che alla fine abbiamo ricevuto errori di connessione simultanei che sono ciò che ci porta al problema.

Prova la seguente query durante il picco:

SELECT
    c.session_id, c.net_transport, c.encrypt_option,
    s.status,
    c.auth_scheme, s.host_name, s.program_name,
    s.client_interface_name, s.login_name, s.nt_domain,
    s.nt_user_name, s.original_login_name, c.connect_time,
    s.login_time
FROM sys.dm_exec_connections AS c
JOIN sys.dm_exec_sessions AS s
    ON c.session_id = s.session_id
ORDER BY c.connect_time ASC

Se ho ragione, troverai un sacco di record restituiti con lo stato di Sleeping, o peggio Running. In questo caso hai problemi ancora più grandi nel livello app.

È possibile eseguire il debug ulteriore copiando il database, utilizzando la query seguente (utilizzando il livello di base per evitare costi eccessivi) e monitorando questo comportamento.

CREATE DATABASE Database1_copy AS COPY OF Database1 ( EDITION = 'basic' );