El curioso caso de HADR_SYNC_COMMIT espera

Estamos notando un patrón interesante de HADR_SYNC_COMMITespera en nuestro entorno. Tenemos una réplica de tres; una primaria, una secundaria de sincronización y una secundaria asíncrona en un centro de datos y acabamos de agregar tres réplicas ASYNC más en otro centro de datos (~ 2400 millas de distancia).

Desde entonces, hemos comenzado a notar un enorme aumento en las HADR_SYNC_COMMITesperas. Cuando miramos las sesiones activas, vemos un montón de COMMIT TRANSACTIONconsultas esperando en la réplica SYNC

De la captura de pantalla, podemos ver claramente que hay un salto en la HADR_SYNC_COMMITespera el 29 de junio, y finalmente eliminamos 'dos' de las tres réplicas asíncronas en el centro de datos remoto en algún momento del mediodía del 1 de julio. Eso redujo considerablemente los tiempos de espera.

Lo que hemos comprobado hasta ahora: cola de envío de registros, cola de rehacer, último tiempo endurecido y último tiempo de confirmación en las réplicas remotas. Tenemos ráfagas continuas de pequeñas transacciones durante el horario comercial y, por lo tanto, las colas de envío son bastante pequeñas en una marca de tiempo dada (en cualquier lugar entre 60 KB y 1 MB).
Las réplicas remotas están casi sincronizadas, hay muy poca diferencia entre el último tiempo de confirmación y el último tiempo endurecido para cualquier lsn individual en las réplicas.

La tubería de red es 10G y modificamos el tamaño del búfer de transmisión de 256 megas a 2 gigas, esto se hizo bajo el supuesto de que la red estaba cayendo paquetes y volviéndolos a transmitir; De cualquier manera, eso no parecía ayudar mucho.

Entonces, me pregunto qué tienen que ver las réplicas ASYNC con las HADR_SYNC_COMMITesperas. ¿No debería la réplica SYNC depender solo de este tipo de espera, qué me estoy perdiendo aquí?

Primero, la descripción del evento de espera con respecto a su pregunta es:

Esperando el procesamiento de confirmación de transacción para las bases de datos secundarias sincronizadas para fortalecer el registro. Esta espera también se refleja en el contador de rendimiento del Retraso de transacción. Este tipo de espera se espera para grupos de disponibilidad sincronizados e indica el tiempo para enviar, escribir y confirmar el registro en las bases de datos secundarias.

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

Al profundizar en la mecánica de esta espera, los bloques de registro se transmiten y endurecen, pero la recuperación no se completa en los servidores remotos. Siendo este el caso y dado que agregó réplicas adicionales, es lógico que su HADR_SYNC_COMMIT pueda aumentar debido al aumento en los requisitos de ancho de banda. En este caso, Aaron Bertrand es exactamente correcto en sus comentarios sobre la pregunta.

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

Profundizando en la segunda parte de su pregunta sobre cómo esta espera podría estar relacionada con la desaceleración de las aplicaciones. Esto creo que es un problema de causalidad. Está viendo cómo aumentan sus esperas y una queja reciente de un usuario y llega a la conclusión potencialmente incorrecta de que los dos tienen una relación cuando este puede no ser el caso en absoluto. El hecho de que haya agregado archivos tempdb y su aplicación haya respondido mejor a mí indica que puede haber tenido algunos problemas de contención subyacentes que podrían haberse exacerbado por la sobrecarga adicional de la sobrecarga del nivel de aislamiento de la instantánea implícita cuando una base de datos está en un grupo de disponibilidad. Esto puede haber tenido poco o nada que ver con sus esperas HADR_SYNC_COMMIT.

Si desea probar esto, puede utilizar un seguimiento de evento extendido que observe el XEvent hadr_db_commit_mgr_update_harden en su réplica principal y obtenga una línea de base. Una vez que tenga su línea de base, puede volver a agregar sus réplicas de una en una y ver cómo cambia la traza. Le recomiendo encarecidamente que use un archivo que resida en un volumen que no contenga ninguna base de datos y que establezca un rollover y un tamaño máximo. Ajuste el filtro de duración según sea necesario para reunir eventos que coincidan con sus esperas para que pueda solucionar y correlacionar aún más con cualquier otro equipo que necesite participar.

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