[SQL Server] Использование trace flag 9592 для сжатия траффика в кластере AlwaysOn

Публикация № 1237484

Администрирование - Производительность и оптимизация (HighLoad)

sqlserver traceflag alwayson

Недавно мы столкнулись с проблемой производительности, при которой дополнительная нагрузка, связанная с записью большого массива данных, приводила к существенным задержкам в операциях записи основного траффика. Найденное решение позволило не только уменьшить влияние нового процесса на основной пользовательский трафик, но и существенно снизить сетевой траффик между синхронными репликами кластера.

Для обеспечения высокой доступности и восстановления при аварии мы используем SQL Server AlwaysOn кластер с синхронными репликами.
При этом сам кластер находится в облаке AWS с репликами в разных датацентрах в рамках одного региона. Если на активном сервере происходит сбой кластер автоматически обнаруживает проблему и переводит пользовательский траффик на другой сервер без потери данных. 

Основной недостаток этой конфигурации - необходимость записать данные на все синхронные реплики кластера до окончания транзации. В нашей конкретной ситуации, операции записи примерно на 40% медленнее, чем если бы это был одиночный сервер. 
Кроме того, любые задержки в сети или дополнительная нагрузка на основном или вторичном сервере напрямую влияют на скорость записи пользовательских транзаций. 

С чем мы и столкнулись в данной ситуации. Был добавлен новый процесс, который записывал большой массив данных и оказал непропорциональное влиятие на общую производительность сервера.

В статистике ожиданий SQL Server видно, что WRITELOG ожидание увеличилось незначительно, а то время как HADR_SYNC_COMMIT ожидание увеличилось многократно.

WRITELOG ожидание / затраты текущего сервера на запись в журнал транзаций.

HADR_SYNC_COMMIT аналогичное ожидание, но на стороне синхронной реплики.

(визуализация данных с помощью ElasticSearch+Kibana - Мониторинг здоровья MS SQL Server)

т.е. явно проблемы с передачей данных вторичному серверу. 

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

Мы не выявили ни одной из этих проблем и решили попробовать включить сжатия траффика между сихронными репликами.

https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/tune-compression-for-availability-group?view=sql-server-ver15

По умолчанию, сжатие не используется для сихронных реплик, но включено для асинхронных.
Обычно сжатие не рекомендуется для сихронных реплик, т.к. это может потребовать дополнительных ресурсов процессора и оказать в целом негативное влияние.
После нескольких экспериментов мы обнаружили, что сжатие траффика не оказывает негативного влияния конкретно в нашей ситуации, но позволяет решить текущую проблему.
Подозреваю, что не последнюю роль играет тип серверов, который мы используем для баз данных - виртуальные машины z1d типа используют один из самых быстрых процессоров доступных в AWS облаке.

Сжатие траффика позволило уменьшить объем передаваемых данных между репликами примерно на 70%, что также положительно сказалось на затратах - траффик между датацентрами AWS не бесплатный даже в рамках одного региона.

Какой я сделал вывод для себя?

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

Для тестирования можно воспользоваться следующими командами:

-- получить список текущих trace flag-ов
DBCC TRACESTATUS;

-- включить trace flag для всех процессов
DBCC TRACEON (9592, -1);

-- отключить trace flag для всех процессов
DBCC TRACEOFF (9592, -1);

Для включения этого параметра на постоянной основе лучше его добавить в командную строку:

 

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. YPermitin 8367 18.05.20 10:15 Сейчас в теме
(0) интересная информация.

+
2. SGordon1 18.05.20 10:36 Сейчас в теме
А такие веселые картинки со временами по типам задержек кто рисует?
Оставьте свое сообщение

См. также

Публикаций не найдено

Попробуйте расширить область поиска, проверьте поисковый запрос и повторите попытку.

Или закажите индивидуальную разработку вашего решения.

Создать заказ на разработку