Чи впливає використання процесора на вартість закордонного доступу до NUMA?

Сценарій

Припустимо, у мене є SQL сервер із 4-ма сокетами з кожним 1 NUMA-вузлом. Кожна розетка має 4 фізичних ядра. Обсяг пам'яті складає 512 ГБ, тому кожен вузол NUMA має 128 ГБ оперативної пам’яті.

Ключова таблиця завантажується в перший вузол NUMA.

Питання

Припустимо, що з цієї таблиці ми читаємо багато трафіку. Якщо всі фізичні ядра сокета, що належить вузлу NUMA, мають 100-відсоткове використання процесора, чи це негативно впливає на вартість не локального доступу до NUMA, що надходить з інших сокетів? Або з іншого боку, ціна нелокального доступу до NUMA незалежно від того, наскільки зайнятий цей сокет?

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

Фон

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

Обтяжливе запитання :-) Я окреслю деякі фактори, що стосуються цього. У будь-якому даному контексті ці фактори та інші можуть змінюватись і давати цікавий результат.

Вибачте, що не зміг зробити це набагато коротше ...

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

1. Накопичений процесор мс проти логічного IO

   Я дуже часто використовую графіки логічного вводу-виводу (або в термінології perfmon "пошук буферних сторінок") щодо використання процесора для того, щоб оцінити ефективність завантаженості процесора та шукати випадків, сприйнятих спінлок.

   Але SQL Server накопичує час процесора з великою кількістю активності, окрім пошуку сторінок і спинлоків:

   • Плани складаються та повторно складаються.
   • Код CLR виконується.
   • Функції виконуються.

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

   У робочих навантаженнях, за якими я зауважую, головним серед цих "не логічних операцій з IO, але процесів" є сортування / хеширування.

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

   Більше про пам’ять робочої області та кількість використаної робочої області використовується в цих публікаціях:

   • 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. Суперечка спінлока під час розподілу пам’яті робочої області

   Ось тут починає веселитися. Я вже описував, що робота над сортуванням та хеш-пам’яттю в робочій пам’яті споживає процесор, але не відображається в цифрах пошуку bpool.

   Суперечка спінлока - ще один шар цієї особливої ​​розваги. Коли пам'ять викрадається з буферного пулу і виділяється для використання проти надання пам’яті запитів, доступ до пам’яті серіалізується за допомогою вимкнення. За замовчуванням це відбувається з ресурсом, розподіленим на рівні вузла NUMA. Таким чином, кожен запит на одному і тому ж вузлі NUMA, що використовує робочу пам’ять, потенційно може відчувати суперечку спінка при крадіжці пам’яті проти грантів. Дуже важливо зауважити: це не ризик суперечки "одноразово на запит", як це було б, якби питання суперечки було в момент фактичного надання. Швидше, це коли пам'ять викрадено у гранті - тож запит із дуже великим грантом пам’яті матиме багато можливостей для спінклінгу, якщо він використовує більшість своїх грантів.

   Trace flag 8048 виконує велику роботу для усунення цієї суперечки шляхом подальшого розподілу ресурсу на базовому рівні.

   Microsoft каже: "враховуйте прапор трассировки 8048, якщо 8 або більше ядер на сокет". Але ... справа не в тому, скільки ядер в сокеті (скільки існує декількох), а скільки можливостей для суперечок у роботі, що проводиться на одному вузлі NUMA.

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

   Я бачив, як ця спінчаста суперечка знижує продуктивність для віртуальних машин лише на 4 vCPU. Trace flag 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. (Також добре розуміти, що вставки сторінок bpool (читання або записування на першій сторінці) підуть у пул у вузлі пам’яті SQLOS, пов’язаному з планувальником, на якому працює працівник. вузол теж.

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

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

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

     У цій публікації обговорюється поєднання розгортки суперечок навколо пам’яті робочої області та нерівномірного розподілу завдань. Дивіться - ці речі справді все плетуть разом :-)

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

5. Відповідне розміщення даних у пулі

   Це умова, яка, на мою думку, є найбільш інтуїтивно зрозумілою при роботі з серверами NUMA. Це також, як правило, не надзвичайно важливо для продуктивності роботи.

   Що станеться, якщо таблиця буде прочитана в пульту на вузлі NUMA 3, а пізніше запит на NUMA-вузол 4 сканує таблицю, виконуючи всі перегляди пулів у вузлах 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. Масовий розлив tempdb повинен бути очевидним під час спостереження за сервером - і замість високого процесора можна очікувати вимірюваного часу очікування запису, пов'язаного з розливом диска.

Натомість, якщо ситуація, яку ви спостерігали, пов'язана з NUMA, я б очікував, що це поєднання перерахованих вище факторів, здебільшого:

1. використання пам’яті робочої області (яка не відображатиметься в логічних підрахунках IO)

2. який може бути перехресним NUMA-вузлом через стійкий стан зовнішньої пам'яті (якщо це так, шукайте відповідні виправлення)

3. і що може спричинити суперечку спінлок у вузлі NUMA кожен раз, коли здійснюється розподіл проти дотації (виправити за допомогою T8048)

4. і може виконуватися працівниками на логічних процесорах, перевантажених іншими працівниками паралельних запитів (при необхідності відрегулюйте максимальний параметр та / або поріг витрат паралелізму)

( будь ласка, оновіть своє запитання за coreinfo -vдопомогою виходу (утиліта sysinternal), щоб отримати кращий контекст вашого процесора / сокетів та розподілу 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, а потім відстежте це значення та відрегулюйте його відповідно до вашого оточення.

Якщо у вас запущено багато запитів adhoc, увімкніть (встановлено значення 1), optimize for ad hoc workloadsщоб запобігти здуття кешу плану.

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

Настійно рекомендую почати збирати інформацію про статистику щодо екземпляра сервера вашої бази даних.

Посилання: Як це працює: SQL Server (локальні, закордонні та віддалені блоки пам'яті NUMA)

По суті, з апаратної точки зору, управління основною пам'яттю від архітектури Nehalem і далі - це управління інтегрованим контролером пам’яті, це на «Un-core» частини центрального процесора, яка відокремлена від частини, на якій живуть фактичні ядра, оскільки пам'ять ефективно "підключена" до кожного процесора, доступ до зовнішньої пам'яті AFAIK здійснюється через швидкий взаємозв'язок (знову від Nehalem далі), я б сказав, що насичення ядра процесора на локальному вузлі NUMA не повинно впливати на віддалений доступ до цієї пам'яті.

Це посилання може бути корисним:

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

Кріс