Il curioso caso di HADR_SYNC_COMMIT attende

Stiamo notando un modello interessante per le HADR_SYNC_COMMITattese nel nostro ambiente. Abbiamo una replica di tre; uno primario, uno secondario di sincronizzazione e uno secondario asincrono in un datacenter e abbiamo appena aggiunto altre tre repliche ASYNC in un altro datacenter (a circa 2400 miglia di distanza).

Da allora, abbiamo iniziato a notare un enorme aumento delle HADR_SYNC_COMMITattese. Quando guardiamo le sessioni attive, vediamo una serie di COMMIT TRANSACTIONquery in attesa sulla replica SYNC

Dallo screenshot, possiamo vedere chiaramente che c'è un salto in HADR_SYNC_COMMITattesa il 29 giugno e alla fine abbiamo lasciato cadere "due" delle tre repliche asincrone nel datacenter remoto a mezzogiorno del 1 ° luglio. Ciò ha notevolmente ridotto i tempi di attesa.

Ciò che abbiamo controllato finora: registra la coda di invio, la coda di ripetizione, l'ultima ora indurita e l'ultima ora di commit sulle repliche remote. Abbiamo continue esplosioni di piccole transazioni durante l'orario di lavoro, e quindi le code di invio sono piuttosto piccole in un dato timestamp (tra 60KB e 1MB).
Le repliche remote sono quasi sincronizzate, c'è una differenza molto piccola tra l'ultimo tempo di commit e l'ultimo tempo indurito per ogni singolo lsn sulle repliche.

La pipe di rete è 10G e abbiamo modificato la dimensione del buffer di trasmissione da 256 mega a 2 concerti, questo è stato fatto supponendo che la rete stesse rilasciando pacchetti e li ritrasmettesse; in entrambi i casi ciò non sembra essere di grande aiuto.

Quindi, mi chiedo cosa hanno a che fare le repliche ASYNC con le HADR_SYNC_COMMITattese? La replica SYNC non dovrebbe dipendere da solo da questo tipo di attesa, cosa mi sto perdendo qui?

Innanzitutto la descrizione dell'evento wait che riguarda la tua domanda è:

In attesa dell'elaborazione del commit delle transazioni per i database secondari sincronizzati per rafforzare il registro. Questa attesa si riflette anche nel contatore delle prestazioni Ritardo transazione. Questo tipo di attesa è previsto per i gruppi di disponibilità sincronizzati e indica il tempo di invio, scrittura e conferma del log nei database secondari.

https://msdn.microsoft.com/en-us/library/ms179984.aspx

Scavando nella meccanica di questa attesa, i blocchi di registro vengono trasmessi e rafforzati, ma il ripristino non viene completato sui server remoti. Stando così le cose e dato che hai aggiunto repliche aggiuntive, è ovvio che il tuo HADR_SYNC_COMMIT potrebbe aumentare a causa dell'aumento dei requisiti di larghezza di banda. In questo caso Aaron Bertrand ha esattamente ragione nei suoi commenti sulla domanda.

Fonte: http://blogs.msdn.com/b/psssql/archive/2013/04/26/alwayson-hadron-learning-series-hadr-sync-commit-vs-writelog-wait.aspx

Scavando nella seconda parte della tua domanda su come questa attesa potrebbe essere correlata ai rallentamenti dell'applicazione. Questo credo sia un problema di causalità. Stai guardando aumentare le tue attese e un recente reclamo da parte degli utenti e trarre la conclusione potenzialmente erroneamente che i due hanno una relazione quando questo potrebbe non essere affatto il caso. Il fatto che tu abbia aggiunto i file tempdb e che la tua applicazione sia diventata più reattiva per me indica che potresti aver avuto alcuni problemi di contesa sottostanti che potrebbero essere stati aggravati dal sovraccarico aggiuntivo del sovraccarico implicito del livello di isolamento dello snapshot quando un database si trova in un gruppo di disponibilità. Questo potrebbe aver avuto poco o nulla a che fare con le tue attese HADR_SYNC_COMMIT.

Se si desidera testarlo, è possibile utilizzare una traccia di eventi estesa che analizzi l'XEvent hadr_db_commit_mgr_update_harden sulla replica primaria e ottenga una baseline. Una volta che hai la tua linea di base, puoi aggiungere nuovamente le repliche una alla volta e vedere come cambia la traccia. Ti incoraggio vivamente a utilizzare un file che risiede su un volume che non contiene alcun database e impostare un rollover e dimensioni massime. Regola il filtro della durata in base alle esigenze per raccogliere eventi corrispondenti alle tue attese in modo da poter risolvere ulteriormente i problemi e correlarli con tutti gli altri team che devono essere coinvolti.

CREATE EVENT SESSION [HADR_SYNC_COMMIT-Monitor] ON SERVER  -- Run this on the primary replica 
ADD EVENT sqlserver.hadr_db_commit_mgr_update_harden(
    WHERE ([delay]>(10))) -- I strongly encourage you to use the delay filter to avoid getting too many events back, this is measured in milliseconds
ADD TARGET package0.event_file(SET filename=N'<YourFilePathHere>')
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)
GO