it-swarm.com.de

Der merkwürdige Fall von HADR_SYNC_COMMIT wartet

Wir bemerken ein interessantes Muster für HADR_SYNC_COMMIT Wartezeiten in unserer Umgebung. Wir haben eine drei Replik; Eine primäre, eine synchrone sekundäre und eine asynchrone sekundäre in einem Rechenzentrum, und wir haben gerade drei weitere ASYNCHRONE Replikate in einem anderen Rechenzentrum (~ 2400 Meilen voneinander entfernt) hinzugefügt.

Seitdem stellen wir eine enorme Zunahme der Wartezeiten von HADR_SYNC_COMMIT Fest. Wenn wir uns die aktiven Sitzungen ansehen, sehen wir eine Reihe von COMMIT TRANSACTION - Abfragen, die auf das SYNC-Replikat warten

Auf dem Screenshot können wir deutlich sehen, dass die Wartezeit von HADR_SYNC_COMMIT Am 29. Juni sprunghaft gestiegen ist, und wir haben schließlich irgendwann am Mittag des 1. Juli 'zwei' der drei asynchronen Replikate im Remote-Rechenzentrum abgelegt. Das hat die Wartezeiten erheblich verkürzt.

image

Was wir bisher überprüft haben - Protokoll-Sendewarteschlange, Wiederherstellungswarteschlange, letzte gehärtete Zeit und letzte Festschreibungszeit auf den Remote-Replikaten. Während der Geschäftszeiten gibt es ständig kleine Transaktionen, und daher sind die Sendewarteschlangen zu einem bestimmten Zeitstempel (zwischen 60 KB und 1 MB) ziemlich klein.
Die Remote-Replikate sind fast synchron, es gibt kaum einen Unterschied zwischen der letzten Festschreibungszeit und der letzten gehärteten Zeit für eine einzelne LSN auf den Replikaten.

Die Netzwerk-Pipe ist 10G und wir haben die Sendepuffergröße von 256 Megabyte auf 2 GB geändert. Dies wurde unter der Annahme durchgeführt, dass das Netzwerk Pakete verworfen und erneut übertragen hat. So oder so schien das nicht viel zu helfen.

Ich frage mich also, was die asynchronen Replikate mit HADR_SYNC_COMMIT Warten zu tun haben. Sollte das Replikat SYNC nicht allein von diesem Wartetyp abhängen, was fehlt mir hier?

11
Arun Gopinath

Zunächst lautet die Beschreibung des Warteereignisses, auf das sich Ihre Frage bezieht:

Warten auf die Transaktions-Commit-Verarbeitung für die synchronisierten sekundären Datenbanken, um das Protokoll zu härten. Diese Wartezeit spiegelt sich auch im Leistungsindikator für die Transaktionsverzögerung wider. Dieser Wartetyp wird für synchronisierte Verfügbarkeitsgruppen erwartet und gibt die Zeit an, zu der das Protokoll an die sekundären Datenbanken gesendet, geschrieben und bestätigt werden soll.

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

Wenn Sie sich mit der Mechanik dieser Wartezeit befassen, werden die Protokollblöcke übertragen und gehärtet, aber die Wiederherstellung wird auf den Remoteservern nicht abgeschlossen. Wenn dies der Fall ist und Sie zusätzliche Replikate hinzugefügt haben, liegt es nahe, dass sich Ihr HADR_SYNC_COMMIT aufgrund der gestiegenen Bandbreitenanforderungen erhöhen kann. In diesem Fall ist Aaron Bertrand in seinen Kommentaren zu der Frage genau richtig.

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

Sehen Sie sich den zweiten Teil Ihrer Frage an, wie diese Wartezeit mit Anwendungsverlangsamungen zusammenhängen kann. Dies ist meines Erachtens ein Kausalitätsproblem. Sie sehen, wie Ihre Wartezeiten zunehmen und eine kürzlich erfolgte Benutzerbeschwerde vorliegt, und ziehen möglicherweise fälschlicherweise die Schlussfolgerung, dass die beiden eine Beziehung haben, wenn dies möglicherweise überhaupt nicht der Fall ist. Die Tatsache, dass Sie Tempdb-Dateien hinzugefügt haben und Ihre Anwendung schneller auf mich reagiert hat, weist darauf hin, dass Sie möglicherweise einige zugrunde liegende Konfliktprobleme hatten, die durch den zusätzlichen Overhead des Overheads der impliziten Snapshot-Isolationsstufe, wenn sich eine Datenbank in einer Verfügbarkeitsgruppe befindet, möglicherweise noch verstärkt wurden. Dies hat möglicherweise wenig oder gar nichts mit Ihren HADR_SYNC_COMMIT-Wartezeiten zu tun.

Wenn Sie dies testen möchten, können Sie eine erweiterte Ereignisablaufverfolgung verwenden, die das hadr_db_commit_mgr_update_harden XEvent auf Ihrem primären Replikat überprüft und eine Baseline abruft. Sobald Sie Ihre Baseline haben, können Sie Ihre Replikate einzeln wieder hinzufügen und sehen, wie sich der Trace ändert. Ich würde Ihnen dringend empfehlen, eine Datei zu verwenden, die sich auf einem Volume befindet, das keine Datenbanken enthält, und einen Rollover und eine maximale Größe festzulegen. Passen Sie den Dauerfilter nach Bedarf an, um Ereignisse zu erfassen, die Ihren Wartezeiten entsprechen, damit Sie weitere Fehler beheben und diese mit anderen beteiligten Teams korrelieren können.

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
7
Travis Page