Влияет ли загрузка ЦП на стоимость доступа к NUMA за рубежом?

сценарий

Давайте предположим, что у меня есть SQL Server с 4 сокетами с каждым 1 узлом NUMA. Каждый сокет имеет 4 физических ядра. Всего 512 ГБ памяти, поэтому каждый узел NUMA имеет 128 ГБ ОЗУ.

Таблица ключей загружается в первый узел NUMA.

Вопрос

Давайте предположим, что у нас много трафика, читающего из этой таблицы. Если все физические ядра сокета, который владеет узлом NUMA, имеют 100-процентную загрузку ЦП, отрицательно ли это влияет на стоимость нелокального доступа NUMA из других сокетов? Или, с другой стороны, стоимость нелокального доступа NUMA не зависит от того, насколько занят этот сокет?

Я надеюсь, что мой вопрос имеет смысл. Пожалуйста, дайте мне знать, если это не так, я постараюсь уточнить.

Задний план

На прошлой неделе у нас возникла проблема с базой данных на нашем производственном сервере, и некоторые из обработанных нами операций оказались более подвержены влиянию, чем другие. У нас были запросы с несколькими логическими чтениями, занимающими более 1 минуты. Мы смотрели на общую загрузку процессора, которая была около 60 процентов. Мы не смотрели на конкретные показатели ЦП сокетов. Показатели ввода / вывода были средними.

Здоровенный вопрос :-) Я обрисую некоторые факторы. В любом конкретном контексте эти и другие факторы могут варьироваться и приводить к интересному результату.

Извините, я не смог сделать это намного короче ...

1. Накопленный процессор MS против логического ввода-вывода
2. Выравнивание узлов логической памяти SQL Server с физическими узлами NUMA
3. Спин-блокировка в распределении памяти рабочей области запроса
4. Назначение задач планировщикам
5. Соответствующее размещение данных в пуле буферов
6. Размещение физической памяти

1. Накопленный процессор MS против логического ввода-вывода

   Я очень часто использую графики логического ввода-вывода (или в терминологии perfmon «поиск страниц в пуле буферов») в зависимости от загрузки ЦП, чтобы измерить эффективность рабочих нагрузок ЦП и искать случаи, подверженные спин-блокировке.

   Но SQL Server накапливает процессорное время с большим количеством активности, кроме поисков страниц и спин-блокировок:

   • Планы составляются и перекомпилируются.
   • Код CLR выполнен.
   • Функции выполняются.

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

   В рабочих нагрузках, которые я наблюдаю, главной среди этих «нелогичных операций ввода-вывода, но загружающих ЦП» является сортировка / хеширование.

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

   Подробнее о памяти рабочего пространства и о том, сколько предоставленного рабочего пространства было использовано, в следующих статьях:

   • http://sql-sasquatch.blogspot.com/2015/08/sql-server-grantedreservedstolen_4.html

   • http://sql-sasquatch.blogspot.com/2015/08/sql-server-workspace-memory-with-twist.html

   • http://sql-sasquatch.blogspot.com/2015/03/resource-governor-to-restrict-max-query.html

2. Выравнивание узлов логической памяти SQL Server с физическими узлами NUMA

   SQL Server (поскольку он включает в себя свои стратегии, учитывающие NUMA) по умолчанию создает узел памяти SQLOS для каждого узла NUMA на сервере. По мере увеличения объема памяти каждое выделение контролируется одним из узлов памяти SQLOS.

   В идеале узлы памяти SQLOS полностью выровнены с физическими узлами NUMA. То есть каждый узел памяти SQLOS содержит память от одного узла NUMA, при этом никакой другой узел памяти SQLOS также не содержит память от того же узла NUMA.

   Однако такая идеальная ситуация не всегда такова.

   В следующем блоге CSS SQL Server Engineers (также включенном в ответ Кина) подробно описывается поведение, которое может привести к постоянному выделению памяти между узлами NUMA для узлов памяти SQLOS. Когда это происходит, влияние на производительность может быть разрушительным.

   • http://blogs.msdn.com/b/psssql/archive/2012/12/13/how-it-works-sql-server-numa-local-foreign-and-away-memory-blocks.aspx

   Было несколько исправлений для особенно болезненного случая постоянных перекрестных ссылок на узлы NUMA. Вероятно, другие в дополнение к этим двум, а также:

   • ИСПРАВЛЕНИЕ: Проблемы с производительностью возникают в средах NUMA во время обработки сторонних страниц в SQL Server 2012 или SQL Server 2014

   • ИСПРАВЛЕНИЕ: Проблемы производительности SQL Server в средах NUMA

3. Спин-блокировка при выделении памяти рабочей области

   Здесь начинается веселье. Я уже описывал такую ​​работу сортировки и хэширования в рабочей области, память потребляет процессор, но не отражается в числах поиска в буле.

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

   Флаг трассировки 8048 отлично справляется с этой проблемой путем дальнейшего разделения ресурса на уровне ядра.

   Microsoft говорит, что «рассмотрим флаг трассировки 8048, если 8 или более ядер на сокет». Но ... на самом деле дело не в том, сколько ядер в сокете (если их несколько), а в том, сколько возможностей для конкуренции в работе, выполняемой на одном узле NUMA.

   На склеенных процессорах AMD (12 ядер на сокет, 2 узла NUMA на сокет) было 6 ядер на узел NUMA. Я видел систему с четырьмя из этих процессоров (то есть с восемью узлами NUMA, по шесть ядер в каждом), которая была заблокирована в конвой спин-блокировки, пока не был включен флаг трассировки 8048.

   Я видел, как этот спин-блокирующий конфликт снижал производительность на виртуальных машинах до 4 виртуальных процессоров. Флаг трассировки 8048 сделал то, что предполагалось при включении в этих системах.

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

   Ожидания CMEMTHREAD сопровождают тот тип спин-блокировки, который устраняет флаг трассировки 8048. Но предостережение: ожидание CMEMTHREAD является подтверждающим симптомом, а не основной причиной этой конкретной проблемы. Я видел системы с высоким «началом ожидания» CMEMTHREAD, где флаг трассировки 8048 и / или 9024 был отложен при развертывании, поскольку накопленное время ожидания CMEMTHREAD было довольно низким. В случае спин-блокировки накопленное время ожидания, как правило, неправильно. Скорее, вы хотите посмотреть на потерянное время ЦП, представленное в основном самими вращениями, во-вторых, связанными ожиданиями, которые представляют потенциально ненужные переключения контекста.

   • Как это работает: CMemThread и их отладка

4. Назначение задач планировщикам

   В системах NUMA соединения распределяются по узлам NUMA (ну, по сути, по группам планировщиков SQLOS, связанным с ними) циклическим перебором, при условии, что нет конечных точек соединения, связанных с конкретными узлами NUMA. Если сеанс выполняет параллельный запрос, существует сильное предпочтение использовать работников с одного узла NUMA. Хммм ... рассмотрим сервер с 4 узлами NUMA со сложным запросом, разбитым на 4 пути, и по умолчанию 0 MAXDOP. Даже если в запросе используются только рабочие потоки MAXDOP, для каждого логического ЦП на узле NUMA будет 4 рабочих потока. Но в сложном плане есть 4 пути - так что каждый логический ЦП на узле NUMA может иметь 16 рабочих - все для одного запроса!

   Вот почему иногда вы видите, как один узел NUMA работает, а другие бездельничают.

   Есть несколько других нюансов в назначении задач. Но главный вывод заключается в том, что занятость процессора не обязательно будет равномерно распределена по узлам NUMA. (Также полезно понимать, что вставки страниц в пул (чтение или запись первой страницы) будут идти в пул в узле памяти SQLOS, связанном с планировщиком, на котором работает рабочий. И украденные страницы будут преимущественно поступать из «локальной» памяти SQLOS узел тоже.

   Я обнаружил, что использование maxdop от 0 до не более 8 полезно. В зависимости от профиля рабочей нагрузки (в первую очередь imo от числа одновременно ожидаемых потенциально долго выполняющихся запросов), может потребоваться переход к MAXDOP = 2.

   Регулирование порога стоимости для параллелизма также может быть полезным. Системы, над которыми я работаю, как правило, потребляют дорогостоящие запросы и редко сталкиваются с планом ниже 50 или 100, поэтому у меня было больше тяги при настройке maxdop (oten на уровне группы рабочей нагрузки), чем при настройке порога стоимости.

   • SQL Server PLE с 8 узлами NUMA

     В этом посте обсуждается комбинация спин-блокировки вокруг памяти рабочего пространства и неравномерного распределения задач. Видите ли, эти вещи действительно переплетаются вместе :-)

   • 40 параллельных параллельных запросов SQL Server + (2 сокета * 10 ядер на сокет) = конвой спин-блокировки

5. Соответствующее размещение данных в пуле

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

   Что произойдет, если таблица будет считана в пул на узле NUMA 3, а затем запрос на узле 4 NUMA сканирует таблицу, выполняя все операции поиска в пуле на узлах NUMA?

   Линчи Ши имеет большой пост об этом влиянии производительности:

   • http://sqlblog.com/blogs/linchi_shea/archive/2012/01/30/performance-impact-the-cost-of-numa-remote-memory-access.aspx

   Доступ к памяти через узлы NUMA влечет за собой небольшую дополнительную задержку памяти. Я уверен, что есть некоторые рабочие нагрузки, которые должны устранить эту дополнительную базовую задержку памяти для оптимальной производительности - это не было проблемой в системах, с которыми я работаю.

   Но - межузловой доступ также приносит другую точку передачи, которая потенциально может насытить. Если активность настолько велика, что пропускная способность памяти между узлами NUMA насыщается, задержка памяти между узлами увеличится. Эта же работа потребует дополнительных циклов ЦП.

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

6. Размещение физической памяти

   Это редкость, но когда это важно, это действительно важно. На большинстве серверов установка памяти почти естественным образом будет сбалансирована между узлами NUMA. Но в некоторых случаях особое внимание необходимо уделять балансировке памяти между узлами. Производительность в некоторых системах может быть абсолютно нарушена, если память была распределена таким образом, что она не сбалансирована. Это все-таки-это-и-забыл-это. Довольно редко можно обнаружить такую ​​проблему после нескольких месяцев производственного обслуживания, а не после первого по-настоящему напряженного дня :-)

БОЛЬШАЯ ОТДЕЛКА!

Кто-то еще отметил, что неправильный выбор плана, возможно, из-за устаревшей статистики, может привести к появлению симптомов, которые вы видели. В моем опыте такого не было. Из-за плохих планов запрос может занять больше времени, чем ожидалось, но обычно потому, что выполняется больше логических операций ввода-вывода, чем необходимо. Или из-за разлива в базу данных. Наблюдение за сервером должно быть очевидным массовым разливом в базу данных tempdb, и вместо высокой загрузки ЦП можно ожидать измеримого времени ожидания для записей на диск, связанных с разливом.

Вместо этого, если наблюдаемая вами ситуация связана с NUMA, я ожидаю, что она будет сочетать перечисленные выше факторы, в основном:

1. использование рабочей области памяти (которая не будет отображаться в логических подсчетах ввода / вывода)

2. который может быть узлом между NUMA из-за постоянного состояния внешней памяти (если это так, ищите соответствующие исправления)

3. и который может вызвать конфликт спин-блокировки в узле NUMA каждый раз, когда выполняется выделение для разрешения (исправлено с помощью T8048)

4. и могут выполняться работниками на логических ЦП, перегруженных другими работниками параллельных запросов (при необходимости корректируйте порог maxdop и / или стоимость параллелизма)

( обновите ваш вопрос с помощью coreinfo -v(утилиты sysinternal), чтобы получить лучший контекст вашего CPU / сокетов и дистрибутива NUMA )

Мы смотрели на общую загрузку процессора, которая была около 60 процентов. Мы не смотрели на конкретные показатели ЦП сокетов. Показатели ввода / вывода были средними.

Мне кажется, что ты лаешь не на то дерево. SQL Server в NUMAкурсе. При использовании кросс-NUMA-доступа к памяти значительно снижается производительность . Вы также можете использовать этот запрос, чтобы увидеть, сколько у NUMAвас узлов и какие ЦП и ядра назначены на какие NUMA:

SELECT parent_node_id, scheduler_id, cpu_id
FROM sys.dm_os_schedulers WITH (NOLOCK) 
WHERE [status] = N'VISIBLE ONLINE';

Или только сколько NUMA:

select COUNT(distinct Parent_node_id)
from sys.dm_os_schedulers
where [STATUS] = 'VISIBLE ONLINE'
    and Parent_node_ID < 64

У нас были запросы с несколькими логическими чтениями, занимающими более 1 минуты.

Обычно это происходит, когда у вас плохие планы запросов, сгенерированные из-за устаревшей статистики. Убедитесь, что ваша статистика обновлена, а индексы правильно дефрагментированы .

Кроме того, вам нужно установить MAXDOP на более разумное значение, чтобы избежать истощения рабочих потоков .

Установите cost threshold of parallelismзначение по умолчанию, равное 5, на хорошее начальное значение, например, 45, а затем следите за этим значением и корректируйте его в соответствии со своей средой.

Если вы выполняете много специальных запросов, включите (установите в 1), optimize for ad hoc workloadsчтобы предотвратить вздутие кэша плана.

Используйте с осторожностью: вы можете использовать T8048, если вы используете SQL Server 2008/2008 R2 на более новых компьютерах с более чем 8 процессорами, представленными для каждого узла NUMA, и есть исправление, если вы работаете на SQL Server 2012 или 2014 .

Настоятельно рекомендуем вам начать сбор статистических данных об экземпляре сервера базы данных.

См .: Как это работает: SQL Server (блоки памяти NUMA локальной, внешней и внешней памяти)

Чисто с аппаратной точки зрения, управление основной памятью из архитектуры Nehalem и далее управляется встроенным контроллером памяти, это находится на «неядерной» части кристалла ЦП, которая отделена от той части, на которой живут реальные ядра, Поскольку память фактически «подключена» к каждому ЦП, доступ к внешней памяти AFAIK осуществляется через соединение быстрого доступа (опять же из Nehalem и далее), поэтому я бы сказал, что насыщение ядра ЦП на локальном узле NUMA не должно влиять на удаленный доступ к этой памяти.

Вы можете найти эту ссылку полезной:

http://cs.nyu.edu/~lerner/spring10/projects/NUMA.pdf

Крис