Любопытный случай HADR_SYNC_COMMIT ждет

Мы замечаем интересную схему HADR_SYNC_COMMITожидания в нашей среде. У нас есть три реплики; один первичный, один вторичный синхронизатор и один вторичный асинхронный в центре обработки данных, и мы только что добавили еще три реплики ASYNC в другой центр обработки данных (на расстоянии ~ 2400 миль).

С тех пор мы начали замечать огромный рост HADR_SYNC_COMMITожиданий. Когда мы смотрим на активные сеансы, мы видим группу COMMIT TRANSACTIONзапросов, ожидающих реплики SYNC

На скриншоте мы ясно видим, что HADR_SYNC_COMMIT29 июня произошел скачок в ожидании, и мы в конечном итоге отбросили «две» из трех асинхронных реплик в удаленном центре данных где-то в полдень 1 июля. Это значительно сократило время ожидания.

Что мы проверили до сих пор - Журнал очереди на отправку, Повторить очередь, время последней защиты и время последней фиксации на удаленных репликах. У нас есть непрерывные пакеты небольших транзакций в рабочее время, и поэтому очереди отправки довольно малы в данный момент времени (где-то между 60 КБ и 1 МБ).
Удаленные реплики почти синхронизированы, разница между временем последнего принятия и последним усиленным временем очень мала для каждого отдельного lsn в репликах.

Канал сети - 10G, и мы изменили размер буфера передачи с 256 мегабайт до 2 гигабайт, это было сделано в предположении, что сеть отбрасывает пакеты и повторно передает их; в любом случае это не очень помогло.

Итак, мне интересно, какое отношение имеют реплики ASYNC к HADR_SYNC_COMMITожиданиям? Разве реплика SYNC не должна зависеть в одиночку от этого типа ожидания, чего мне здесь не хватает?

Сначала описание события ожидания, которое касается вашего вопроса:

Ожидание обработки фиксации транзакции для синхронизированных вторичных баз данных, чтобы укрепить журнал. Это ожидание также отражается счетчиком производительности задержки транзакции. Этот тип ожидания ожидается для синхронизированных групп доступности и указывает время отправки, записи и подтверждения журнала во вторичные базы данных.

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

Окунувшись в механизм этого ожидания, вы получаете блоки журналов, которые передаются и укрепляются, но восстановление на удаленных серверах не завершено. Учитывая это и учитывая, что вы добавили дополнительные реплики, вполне вероятно, что ваш HADR_SYNC_COMMIT может увеличиться из-за увеличения требований к пропускной способности. В этом случае Аарон Бертран совершенно прав в своих комментариях по этому вопросу.

Источник: http://blogs.msdn.com/b/psssql/archive/2013/04/26/alwayson-hadron-learning-series-hadr-sync-commit-vs-writelog-wait.aspx

Углубившись во вторую часть вашего вопроса о том, как это ожидание может быть связано с замедлением работы приложений. Я считаю, что это проблема причинности. Вы ожидаете увеличения своих ожиданий и недавней жалобы пользователя и, возможно, ошибочно делаете вывод о том, что у обоих есть отношения, когда это может вообще не иметь место. Тот факт, что вы добавили файлы tempdb, и ваше приложение стало более отзывчивым для меня, указывает на то, что у вас могут быть некоторые проблемы с конфликтами, которые могли быть усугублены дополнительными издержками неявных издержек уровня изоляции моментальных снимков, когда база данных находится в группе доступности. Возможно, это не имело ничего общего с Вашими ожиданиями HADR_SYNC_COMMIT.

Если вы хотите проверить это, вы можете использовать расширенную трассировку событий, которая рассматривает XEvent hadr_db_commit_mgr_update_harden на вашей основной реплике и получить базовый уровень. Когда у вас есть базовый уровень, вы можете добавлять свои реплики по одному за раз и видеть, как изменяется трассировка. Я настоятельно рекомендую вам использовать файл, который находится на томе, который не содержит каких-либо баз данных, и установить ролловер и максимальный размер. При необходимости измените фильтр продолжительности, чтобы собрать события, соответствующие вашим ожиданиям, чтобы вы могли в дальнейшем устранять неполадки и соотносить это с любыми другими командами, которые должны быть вовлечены.

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