Встретил похожую проблему. Причем при попытке сжать раздутый лог появилась похожая проблема и пришлось отменять.
При обработке ребилде индекса размером около 5 ГБ вверх полезли ожидания HADR_SYNC_COMMIT, у пользовательских запросов последнее ожидание стало HADR_SYNC_COMMIT, начали блокировть друг друга. (а о сессию ребилда нет).
По дашборду AlwaysOn виден рост Log send queue size и redo queue size.
При этом между машинами сетка 10Гбит, а нагрузку в этом момент показывает около 40 mbytes, что далеко от максимума.
Реплики синхронные.
Этот же кластер AlwaysOn из 2 ВМ на прошлом железе сидел на одном хосте, потому что на разных даже на пользовательских запросах вставал в HADR_SYNC_COMMIT, сетевики присылали скрин передачи файла между хостами с нормальной скоростью и говорили, что всё ок. Но что-то такой метод не убеждает.
На новом железе реплики смогли жить уже на разных нодах, но при заметных изменениях опять лезет вверх HADR_SYNC_COMMIT. Базы большие, как и таблицы, там и пользовательские изменения могут быть значительными.
Проблему хочется решить, а не убирать вызывающие действия. Пока выглядит, что что-то настроено не так. Возможная настройка MS SQL (но вряд ли, ничего не менялось, а на разных хостах виртуализации работа разная), настройка ВМ или сетевая. У кого-то есть мысли в какую сторону искать и что проверить?

Александр Гладченко,

На время убирали дефрагментацию индексов, но встретили пару случаев со странным выполнением запросов на ноде для чтения, тогда помог ребилд одного из индексов участников. Про SSD и дефрагментация руководство в курсе, их это устраивает. Настаивают на возвращении раз в неделю, смысла спорить особо нет. Да и рост HADR_SYNC_COMMIT наблюдается не только во время обслуживания индексов, просто им проще всего отловить.

Для однократного выполнения перевести в асинхронный режим возможно, но для постоянного не стоит. Да и сколько будет идти синхронизация после? Сейчас при минуте выполнения, при остановке потом ещё минуты 2 в норму приходит.

Вот по redo можно проверить. При проверке sp_who на ноде для чтения есть сессии background PARALLEL REDO TA, но не по всем базам, при этом по основным БД таких сессий сейчас не вижу. TF 3459 не включен и он вроде на весь сервер, а не отдельные БД.

Александр Гладченко,

Вот тоже наткнулся на информацию, что там первый попадают, а не все.
Версия 2017 Enterprise.
Вижу 6 из 18. Примерно самые мелкие.

When the host server has 32 or more CPU cores, each database will occupy 16 parallel redo worker threads and one helper worker thread. It means that all databases starting with the 7th database (ordered by database id ascending) that has joined availability group it will be in single thread redo or serial redo irrespective which database has actual redo workload. If a SQL Server Instance has a number of databases, and it is desired for a particular database to run under parallel redo model, the database creation order needs to be considered. Same idea can be applied to force a database always runs in serial redo model as well.

Базы добавлены в Always On добавлены давным давно, порядок мог быть любой. Если при включении инстанса набирается заново, то основные тяжелые базы будут последними подниматься.

Вроде бы упоминается возможно заставить базу всегда работать в serial redo. Попробую поискать как определенную базу из мелких заставить работать без параллельного и освободить места.

Александр Гладченко,

На постоянной основе пока варианта отключить только для конкретной базы не вижу. Нужные базы с ID 8 и 9. При этом работает для 14, 20, 21.

Через флаг для всего сервера можете подсказать? Там на вторичной ноде нужно делать?
Вроде так включить\выключить. Рестарт пишут, что с 2017 для включения параллельного redo не нужен.

DBCC TRACEON (3459,-1);
GO
DBCC TRACEOFF (3459,-1);

Правда читал, что у кого-то наоборот с параллельным редо ещё проблемы начались, ну отключить тут проще.