El curioso caso de HADR_SYNC_COMMIT espera


11

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.

imagen

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í?


1
Entonces, ¿hay realmente un problema? Mucha gente solo mira sus esperas y dice: hey, esta es la espera más alta, ¡debe ser un problema! Una espera es solo un número y siempre habrá uno con el número más alto; no necesariamente significa que haya un problema de rendimiento que resolver. Para esta espera específicamente, parece que ha descartado la causa más común , y dado que sus secundarias no se están quedando atrás, no gastaría mucha energía en este "problema" hasta
Aaron Bertrand

tiene algún otro síntoma junto con un número alto en un contador de espera, y que puede correlacionarse con el contador de espera alto.
Aaron Bertrand

@AaronBertrand Sí, lo hay. Los spids activos en la réplica principal esperan que los bloques de registro se endurezcan en la sincronización secundaria, este retraso / espera a su vez hace que la aplicación se ralentice drásticamente. El pagelatch_up espera el 9 de julio que ves en la captura de pantalla fue debido a la contención de tempdb (espera en la página pfs), hemos agregado más archivos desde el lado dba y la gente de la aplicación ajustó los procedimientos almacenados golpeando el tempdb muy frecuentemente para mitigar ese problema. Volviendo a hadr_sync_waits, ¿por qué las confirmaciones asincrónicas afectan a los hadr_sync_commits en primer lugar? Gracias.
Arun Gopinath

1
Supongo que el tiempo de espera incluye el tiempo de transferencia, y los datos se transfieren juntos, el asíncrono simplemente no tiene que esperar el confirmación de confirmación. Por lo tanto, mientras más secundarios tenga, ya sea sincronizado o asíncrono, más tiempo pasará transfiriendo la actividad de registro (esto no es necesariamente la hora del reloj, ya que algunos pueden ser concurrentes). Es posible que desee que la gente de la red intente ver si hay una latencia indebida, ya sea en general o a medida que agrega más secundarios.
Aaron Bertrand

Respuestas:


7

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
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.