Автоматическая Soft-NUMA. Подводные камни

Автоматическая Soft-NUMA. Подводные камни

Чтобы у вас было полное понимание о чём пойдёт речь, рекомендую изучить статью о базовом устройстве автоматической Soft-Numa.

Если у вас нет времени, то я бы хотел чтобы вы усвоили следующее:

Говоря кратко о сути проблемы, конкурирующий спинлок не может масштабироваться больше чем на 8 ядер.

На системах, у которых в одном NUMA узле 8 и более физических ядер, SQL Server 2016, во время запуска, запрашивает топологию аппаратных компонент сервера и автоматически настраивает Soft NUMA. Такое секционирование ресурсов приводит к множеству настроек на уровне ядра базы данных, которые призваны повысить масштабируемость и производительность сервера.

То есть SQL Server пытается сохранять количество ядер в NUMA менее 8 и если их количество превышает данное число, то по-умолчанию, начиная с SQL Server 2016, будут созданы «виртуальные» Numa ноды.

И вот как раз о балансировке количества ядер в Numa я и хотел сегодня с вами поговорить.

Начальные установки:

  1. Виртуальная машина
  2. Лицензия SQL Server на 20 ядер
  3. 23 ядра на хосте
  4. 2 Numa ноды на хосте
  5. Hyper threading отсутствует

Если у вас SQL Server 2016 и вы не трогали настройку по-умолчанию в sp_configure (automatic soft-NUMA disabled), то SQL Server применит механизм автоматической Soft-Numa и попробует разбить наши 2 NUMA с 12 и 11 ядрами в каждой на равные части с менее чем 8 ядрами в каждой. В нашем случае он попытается поделить на 4 NUMA: 6-6-6-5.

На первый взгляд всё выглядит логично, но SQL Server, при разделении, не учитывает что ему доступно только 20 ядер и, по этой причине, реальное разделение будет 6-6-6-2, то есть для последней NUMA он сможет захватить только 2 ядра вместо 5 планируемых.

Теперь, когда у нас есть сильный перекос в ядрах по NUMA, SQL Server будет стараться равномерно распределять нагрузку между этими NUMA, то есть он примерно равномерно распределит worker`ов по получившимся 4 NUMA. В результате мы можем получить медленные запросы, при большом количестве свободных ядер.

Почему это происходит? Предположим у нас есть 20 worker’ов, которые разбиты на 4 NUMA (по 5 worker’ов на NUMA) и они разбирают поступающие task’и (задачи). Первые 3 группы будут работать хорошо, так как у них в распоряжении будет по 6 ядер, а вот последняя группа, будем иметь всего 2 ядра и все задачи, что на неё попадут, будут выполняться только на них. Если ваша система не потребляет много CPU или на последнюю группу не попадают такие запросы, то вы можете даже не заметить разницы, в противном случае наши 5 worker’ов (в действительности их будет больше) будут выстраиваться в очередь на ожидания CPU и как результат мы получим замедление таких запросов. Без понимания данной особенности, может быть очень сложно понять почему большинство запросов выполняются быстро, а некоторые существенно медленнее.

Как посмотреть распределение:

  1. В ERROR LOG вы можете найти следующие записи и если их количество больше чем количество NUMA на операционной системе, значит у вас активизировалась автоматическая Soft-NUMA (обратите внимание когда используется всего 1 NUMA, вы можете получить 2 записи в ERROR LOG):
  2. Так же количество NUMA можно получить следующим запросом:
  3. А вот посмотреть сколько ядер получила каждая NUMA можно так:

Как исправить ситуацию:

Самым простым решением будет просто отключить данную опцию через sp_configure:

Обратите внимание, что действительное отключение автоматической Soft-NUMA произойдёт только после перезагрузки SQL Server.

Запись опубликована в рубрике Оптимизация с метками , , , . Добавьте в закладки постоянную ссылку.

Добавить комментарий

Войти с помощью: