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

18.05.20

База данных - HighLoad оптимизация

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

Для обеспечения высокой доступности и восстановления при аварии мы используем 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);

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

 

sqlserver traceflag alwayson

См. также

Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Анализ простого плана запроса. Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы.

13.03.2024    2393    spyke    25    

38

Анализируем SQL сервер глазами 1С-ника

HighLoad оптимизация Инструменты администратора БД Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Обработка для простого и удобного анализа настроек, нагрузки и проблем с SQL сервером с упором на использование оного для 1С. Анализ текущих зааросов на sql, ожиданий, конвертация запроса в 1с и рекомендации где может тормозить

1 стартмани

15.02.2024    7355    149    ZAOSTG    66    

95

Удаление строк из таблицы значений различными способами с замером производительности

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Встал вопрос: как быстро удалить строки из ТЗ? Рассмотрел пять вариантов реализации этой задачи. Сравнил их друг с другом на разных объёмах данных с разным процентом удаляемых строк. Также сравнил с выгрузкой с отбором по структуре.

09.01.2024    5766    doom2good    48    

63

Опыт оптимизации 1С на PostgreSQL

HighLoad оптимизация Бесплатно (free)

При переводе типовой конфигурации 1C ERP/УТ/КА на PostgreSQL придется вложить ресурсы в доработку и оптимизацию запросов. Расскажем, на что обратить внимание при потерях производительности и какие инструменты/подходы помогут расследовать проблемы после перехода.

20.11.2023    8588    ivanov660    6    

75

ТОП проблем/задач у владельцев КОРП лицензий 1С на основе опыта РКЛ

HighLoad оптимизация Бесплатно (free)

Казалось бы, КОРП-системы должны быть устойчивы, быстры и надёжны. Но, работая в рамках РКЛ, мы видим немного другую картину. Об основных болевых точках КОРП-систем и подходах к их решению пойдет речь в статье.

15.11.2023    4999    a.doroshkevich    20    

72

Начните уже использовать хранилище запросов

HighLoad оптимизация Запросы

Очень немногие из тех, кто занимается поддержкой MS SQL, работают с хранилищем запросов. А ведь хранилище запросов – это очень удобный, мощный и, главное, бесплатный инструмент, позволяющий быстро найти и локализовать проблему производительности и потребления ресурсов запросами. В статье расскажем о том, как использовать хранилище запросов в MS SQL и какие плюсы и минусы у него есть.

11.10.2023    15959    skovpin_sa    14    

98

Как эффективно настроить autovacuum в Postgres для 1С

HighLoad оптимизация Администрирование СУБД Платформа 1С v8.3 Бесплатно (free)

Кто не любит убирать мусор? Думаю, практически все, а вот в Postgres это обязательный ритуал для эффективной работы. Как эффективно настроить уборку за 1С в Postgres, можно прочитать в этой статье и еще раз задуматься о бесплатности Postgres.

05.08.2023    4974    1CUnlimited    5    

51
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. пользователь 18.05.20 10:15
(0) интересная информация.

+
2. SGordon1 18.05.20 10:36 Сейчас в теме
А такие веселые картинки со временами по типам задержек кто рисует?
4. Shmell 532 05.11.20 16:20 Сейчас в теме
Нужно взять на заметку. Спасибо!
Оставьте свое сообщение