Узел numa что это

Записки виртуального админа

Новости, обзоры и заметки о виртуальных машинах и платформах виртуализации.

четверг, 27 мая 2010 г.

Сайзинг ВМ и NUMA системы

С появлением vSphere стало возможным создавать ВМ с 8 процессорами и 255 GB памяти. И хотя я не много видел машин с 32+GB, я получаю много вопросов о 8-процессорных ВМ. Из-за архитектуры современных процессоров ВМ с более чем 4-мя процессорами могут испытывать снижение скорости работы с памятью на NUMA системах. И хотя степень снижения сильно зависит от типа нагрузки, любой администратор должен избегать проблем с производительностью.

Большинство современных процессоров, таких как новенькие Intel Nehalem и закаленные в боях AMD Opteron, являются представителями архитектуры NUMA (Non-Uniform Memory Access). У каждого процессора есть своя собственная «локальная» память, а процессор и память вместе объединяются в узел NUMA. ОС будет пытаться использовать локальную память процессора, но при необходимости может обращаться и к «удаленной» памяти, принадлежащей другому NUMA узлу. Время доступа к памяти может варьироваться, в зависимости от расположения памяти относительно процессора, потому что обращение к собственной локальной памяти происходит быстрее, чем к удаленной.

Рисунок 1: Доступ к локальной и удаленной памяти

При обращении к удаленной памяти увеличивается задержка, соотв. нужно избегать этого до последнего. Но как можно гарантировать, что большинство обращений будут локальными?

Западня номер 1 при сайзинге ВМ: сайзинг vCPU и первичное размещение

Рисунок 2: Размещение vCPU на не-NUMA системе

Рисунок 3: Размещение vCPU на NUMA системе

В настоящий момент AMD и Intel предлагают 4-ядерные процессоры, но если пользователь захочет создать 8-процессорную ВМ? Если ВМ не умещается внутри одного NUMA узла, то vCPU распределются традиционным образом, по всей системе. ВМ не получит ничего от оптимизации доступа к памяти, и соотв. при доступе процесса к удаленной памяти будет появляться дополнительная задержка.

Западня номер 2: сайзинг памяти ВМ и размер локальной памяти

Рисунок 4: общая статистика памяти в esxtop

Рисунок 5: Изменяем статистику

На рисунке 6 можно увидеть NUMA статистику для уже упомянутого ESX сервервера с полностью загруженным NUMA узлом. Поле N%L показывает процент памяти, размещенной локально (локальность памяти) для ВМ.

Рисунок 6: Статистика NUMA

Как мы видим, немногие машины работают с удаленной памятью. Man страница для esxtop поясняет значение всех параметров:

Transparent page sharing and локальность памяти.

Так что будет с transparent page sharing (TPS)? Ведь работа TPS может увеличить задержку, если ВМ с узла 0 будет разделять страницу памяти с ВМ с узла 1. К счастью, инженеры VMware подумали об этом, и по умолчанию TPS между узлами отключена с целью повышения локальности памяти. TPS все еще работает, но будет разделять доступ к страницам памяти только внутри узла. Задержки при доступе к удаленной памяти перевешивают положительный эффект экономии памяти на уровне всей системы.

Источник

Non-Uniform Memory Architecture (NUMA): исследование подсистемы памяти двухпроцессорных платформ AMD Opteron с помощью RightMark Memory Analyzer

Неоднородная архитектура памяти (NUMA) как особый вид организации подсистемы памяти существует уже довольно давно. Ее наиболее наглядный и доступный вариант представлен подсистемой памяти многопроцессорных платформ AMD Opteron, и существует он, можно сказать, с момента анонса самих процессоров AMD Opteron 200-х и 800-х серий, поддерживающих многопроцессорные конфигурации. Вместе с тем, изучение этой архитектуры памяти (здесь и далее мы будем иметь в виду исключительно ее «AMD-шный вариант») на низком уровне, анализ ее преимуществ и недостатков до сих пор не проводились. Этим мы и решили заняться в настоящей статье, благо в распоряжении нашей тестовой лаборатории оказалась очередная двухпроцессорная система на базе процессоров AMD Opteron. Но для начала, напомним основные особенности этой архитектуры.

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

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

Что же предлагает AMD в своем варианте неоднородной архитектуры памяти NUMA (ее полное название — Cache-Coherent Non-Uniform Memory Architecture, ccNUMA)? Все предельно просто — поскольку процессоры AMD64 обладают интегрированным контроллером памяти, каждый процессор в многопроцессорной системе наделен своей «собственной» памятью. При этом, процессоры связаны между собой посредством шины HyperTransport, не имеющей прямого отношения к подсистеме памяти (чего не скажешь о традиционной FSB).

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

Однако «правильная организация доступа к памяти» здесь — ключевое и критически важное понятие. Платформы с архитектурой NUMA должны поддерживаться как со стороны ОС (хотя бы для того, чтобы сама система и приложения могли «увидеть» память всех процессоров, как единый блок памяти), так и со стороны приложений. Последние версии Windows XP (SP2) и Windows Server 2003 полностью поддерживают NUMA-системы (для 32-разрядных версий необходимо включение режима Physical Address Extension (ключ /PAE в boot.ini), который, к счастью, для AMD64-платформ включен по умолчанию, поскольку необходим для реализации Data Execution Prevention). Что касается приложений, здесь, прежде всего, имеется в виду нежелательность возникновения ситуации, когда приложение размещает свои данные в области памяти одного процессора, после чего обращается к ним с другого процессора. А как влияет соблюдение или несоблюдение этой рекомендации, мы сейчас и рассмотрим.

Конфигурация тестового стенда и ПО

Результаты исследований

Исследование проводилось в стандартном режиме тестирования подсистемы памяти любой платформы. Измерялись: средняя реальная пропускная способность памяти (ПСП) при операциях простого линейного чтения и записи данных из памяти/в память, максимальная реальная ПСП при операциях чтения (с программной предвыборкой данных, Software Prefetch) и записи (методом прямого сохранения данных, Non-Temporal Store), а также латентность памяти при псевдослучайном и случайном обходе 16-МБ блока данных.

Некоторым отличием от общепринятой методологии явилась «привязка» тестов к определенному физическому процессору — возможность, уже давно реализованная в RMMA, да все никак не опробованная на практике. Ее суть такова: размещение блока данных в памяти всегда осуществляется первым процессором (что для NUMA-aware OS означает, что блок будет выделен в физической памяти первого процессора), после чего запуск тестов может быть осуществлен как на том же, первом, так и на любом другом присутствующем в системе процессоре. Это позволяет нам оценить скорость обмена данными между процессором и памятью (и прочие характеристики) — как «своей», так и «чужой», принадлежащей соседнему процессору.

Симметричный режим «2+2», No Node Interleave

Настроек подсистемы памяти в BIOS двухпроцессорной системы AMD Opteron оказалось довольно много. А именно, настраиваются как минимум три параметра (по принципу Disabled/Enabled, или Disabled/Auto), что дает нам общее число вариантов — 8. Это: Node Interleave (чередование памяти между «узлами», то есть интегрированными контроллерами процессоров — замечательная возможность, которую мы подробно рассмотрим ниже), Bank Interleave (классическое чередование доступа к логическим банкам модулей памяти), а также Memory Swizzle (нечто похожее на Bank Interleave, но так до конца и не понятое :)). Поскольку изменение последнего параметра не оказывало ощутимого влияния на результаты тестов, было решено оставить его по умолчанию (Enabled). Остальные параметры варьировались, и в первой серии тестов была выбрана симметричная конфигурация «2+2» (по 2 модуля на каждый процессор), Node Interleave был отключен, а параметр Bank Interleave варьировался между Disabled и Auto (последнее означает, что чередование банков осуществляется в соответствии с характеристиками самого модуля).

Доступ процессора к «своей» памяти (CPU 0) дает вполне привычную картину, пожалуй, даже отлично выглядящую, учитывая, что используется регистровая память DDR-400 с не самыми быстрыми таймингами (3-3-3-8). Включение Bank Interleave приводит к улучшению некоторых показателей ПСП (особенно — средней реальной ПСП на запись, с одновременным увеличением разброса ее величины) и практически не влияет на задержки.

Обращение процессора к «чужой» памяти (CPU 1) приводит к заметному ухудшению всех показателей подсистемы памяти. Прежде всего, это двукратное падение максимальной реальной ПСП на чтение/запись (получается как бы одноканальный режим доступа, но с чем связано такое ограничение — не совсем понятно, поскольку частота HyperTransport в нашем случае составляет 1000 МГц, что обеспечивает пиковую пропускную способность межпроцессорного соединения 4.0 ГБ/с). Снижение средней реальной ПСП менее ощутимо, а задержки возрастают на 50-60%.

Таким образом, «неоднородность» подсистемы памяти, о которой мы упоминали в теоретической части — налицо (и, разумеется, не только в терминах латентности, но и ПСП). Что подтверждает необходимость использования не только NUMA-aware OS, но и специально оптимизированных многопоточных приложений, в которых каждый поток самостоятельно выделяет память под свои данные и работает со своей областью памяти. В противном случае (однопоточные приложения и многопоточные, «не задумывающиеся» о правильном с точки зрения NUMA размещении данных в памяти) следует ожидать снижение производительности подсистемы памяти. Рассмотрим это на примере однопоточных приложений, на сегодняшний день по-прежнему представляющих большинство ПО. Известно, что в многопроцессорной системе диспетчер ОС назначает приложениям процессорное время так, чтобы разделить его поровну между всеми имеющимися процессорами (таким образом, в случае двухпроцессорной системы примерно 50% приходится на первый процессор, и 50% — на второй). Таким образом, момент размещения памяти обязательно придется на какой-нибудь из процессоров (например, CPU0), в то время как код приложения, осуществляющий доступ к этим данным, будет исполняться как на CPU0, так и на CPU1. И половину времени подсистема памяти будет работать с полной эффективностью, а половину — со вдвое сниженной, как показывают наши тесты. Поэтому, как это ни странно, эффективность работы с памятью таких приложений можно повысить, принудительно «привязав» их к одному из процессоров (задав Process Affinity), что, в общем-то, сделать не так и сложно.

Хуже будет обстоять дело в случае неоптимизированных под NUMA многопоточных приложений, так же размещающих свои данные в памяти лишь одного из процессоров. Такая конфигурация может даже уступать традиционным SMP-вариантам — суммарная пропускная способность будет ограничена пропускной способностью одного из контроллеров памяти, а задержки доступа будут неравномерными. Тем не менее, даже в этом непростом случае архитектура NUMA в ее AMD-шном воплощении предусматривает выход из ситуации, о котором ниже.

Несимметричный режим «4+0»

А пока мы решили немного. «удешевить» систему — то есть имитировать ситуацию, преобладающую среди более дешевых двухпроцессорных плат под AMD Opteron, когда модули памяти можно установить всего для одного процессора — для второго процессора такая память принудительно становится «чужой». Собственно, исходя из теоретических предположений, ожидать сильно отличающихся результатов в этом случае явно не стоит — ситуация отличается ровно тем, что у «своего» процессора памяти стало в 2 раза больше, а у «чужого» ее как не было, так и нет. Поэтому приводим мы их исключительно для полноты картины.

Так оно и есть — теория подтверждается практикой. Небольшие отличия наблюдаются лишь при включении Bank Interleave — в этом случае несколько снижается ПСП и увеличивается ее разброс (столь сильный разброс связан с плавным возрастанием ПСП на запись при увеличении размера блока от 4 до 16 МБ). Вместе с тем, в рамках нашего исследования это не столь важно, поскольку отражает лишь внутренние особенности функционирования Bank Interleave при использовании либо двух, либо четырех конкретных модулей памяти.

Зададимся лучше более важным вопросом: означают ли наши результаты то, что можно сэкономить и использовать более дешевый вариант построения подсистемы памяти? Делать этого однозначно не стоит, причем как в случае NUMA-оптимизированных приложений, так и без них. В первом случае причина ясна — хорошо оптимизированные многопоточные приложения, если они требовательны к ПСП, получат максимум от симметричной организации подсистемы памяти. А во втором случае, симметричная организация «2+2» вместо асимметричной «4+0» позволяет задействовать режим Node Interleave. или просто выиграть от правильной «привязки» приложений к процессорам.

Симметричный режим «2+2», Node Interleave

Вот мы и добрались до самого интересного момента — решения для обычных приложений, ничего не знающих об архитектуре NUMA. Суть его весьма проста, и заключается она в чередовании памяти по 4-КБ страницам между модулями, находящимися на разных «узлах» (контроллерах памяти). В случае двухпроцессорной системы можно сказать, что все четные страницы «достаются» первому процессору, а все нечетные — второму. В результате получается — независимо от того, на какой из процессоров приходится момент размещения данных в памяти, данные будут размещены поровну в пространстве памяти обоих процессоров. И независимо от того, на каком из процессоров исполняется код, половина обращений к памяти будет относиться к «своей» памяти, а половина — к «чужой». Что же, посмотрим, как это проявляет себя на практике.

Полная симметрия по всем показателям, «неоднородности» архитектуры памяти — как не бывало! Задержки при доступе к памяти при этом составляют истинно среднюю величину (например, при псевдослучайном доступе: (45 + 70) / 2 = 57.5 нс), с ПСП дела обстоят несколько хуже — вместо ожидаемой теоретической величины (6.4 + 3.2 / 2) = 4.8 МБ/с мы наблюдаем лишь 4.2 МБ/с.

Заметим, однако, что примерно такие же величины мы получили бы и без включения Node Interleave — для простого однопоточного приложения, не «привязанного» к определенному процессору. Более того, принудительная «привязка» приложения к процессору, как мы говорили выше, позволяет даже увеличить ПСП и снизить латентности. Таким образом, единственная адекватная область применения Node Interleave — это лишь неоптимизированные многопоточные приложения, которые в противном случае будут упираться в ПСП одного из контроллеров памяти.

Заключение

* в случае «привязки» приложения к одному из процессоров

Итак, SMP-системы (двухпроцессорные Intel Xeon, а также. любые существующие на сегодняшний день двухъядерные процессоры) — теоретическая ПСП во всех случаях ограничена цифрой 6.4 ГБ/с, ибо это — пиковая ПС единой и единственной процессорной шины.

Недорогие, несимметричные NUMA-системы выглядят не многим лучше, а то и хуже традиционных SMP-систем. Хуже — в случае однопоточных приложений, если их не «привязывать» к тому процессору, который обращается с памятью. Пиковая ПСП во всех остальных случаях здесь также ограничена цифрой 6.4 ГБ/с — то есть пропускной способностью единственного имеющегося в системе интерфейса памяти.

Симметричные NUMA-системы практически во всех случаях обладают преимуществом как над SMP, так и несимметричными NUMA-системами. Достигнуть пиковой ПСП 12.8 ГБ/с на таких платформах могут либо специальные NUMA-оптимизированные приложения, либо. два обычных, однопоточных приложения, «раскиданных» каждое по своему процессору.

Наконец, что же дает симметричным NUMA-платформам включение режима Node Interleave? Преимущество можно увидеть только в одном случае — неоптимизированных многопоточных приложений (да еще и, конечно же, при условии, что каждый из потоков будет интенсивно обращаться с данными, находящимися в памяти). Если же грамотно запускать однопоточные приложения, либо использовать NUMA-оптимизированные — включение этого режима однозначно не нужно, оно может лишь ухудшить производительность.

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

Источник

Поддержка NUMA

Традиционная модель многопроцессорной поддержки — это симметричный многопроцессорный (SMP). В этой модели каждый процессор имеет равный доступ к памяти и операциям ввода-вывода. По мере добавления процессоров процессорная шина преобразуется в ограничение производительности системы.

Конструкторы систем используют неоднородный доступ к памяти (NUMA) для увеличения скорости процессора без увеличения нагрузки на процессорную шину. Архитектура является неоднородной, так как каждый процессор близко к некоторым частям памяти и более отдален от других частей памяти. Процессор быстро получает доступ к памяти, к которой он близок, в то время как может потребоваться больше времени для получения доступа к памяти, которая находится дальше.

В системе NUMA процессоры размещаются в небольших системах, именуемых узлами. Каждый узел имеет свои собственные процессоры и память и подключается к более крупной системе через шину Interconnect, ориентированную на кэш.

Система пытается повысить производительность, планируя потоки на процессорах, которые находятся в том же узле, что и используемая память. Он пытается удовлетворить запросы на выделение памяти в пределах узла, но при необходимости выделит память с других узлов. Он также предоставляет API, чтобы сделать топологию системы доступной для приложений. Вы можете повысить производительность приложений с помощью функций NUMA, чтобы оптимизировать планирование и использование памяти.

Поддержка NUMA в системах с более чем 64 логическими процессорами

В системах с более чем 64 логическими процессорами узлы назначаются группам процессоров в соответствии с емкостью узлов. Емкость узла — это количество процессоров, имеющихся при запуске системы вместе со всеми дополнительными логическими процессорами, которые могут быть добавлены во время работы системы.

Windows server 2008, Windows Vista, Windows Server 2003 и Windows XP: Группы процессоров не поддерживаются.

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

Идеальный узел NUMA для нового процесса можно запросить с помощью _ атрибута потока процесса _ _ предпочтительный _ Расширенный атрибут Node при создании процесса. Как и идеальный для потоков процессор, идеальный узел является указанием планировщика, который назначает новый процесс группе, содержащей запрошенный узел, если это возможно.

поведение, начиная с Windows 10 сборки 20348

начиная с Windows 10 сборки 20348, поведение этой и других функций NUMA было изменено для улучшения поддержки систем с узлами, содержащими больше процессоров 64.

создание «фиктивных» узлов для размещения сопоставления 1:1 между группами и узлами привело к путанице в работе при обнаружении непредвиденного числа узлов NUMA и так, начиная с Windows 10 сборки 20348, операционная система изменилась, чтобы разрешить связь между несколькими группами с узлом, поэтому теперь можно сообщить о истинной топологии NUMA системы.

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

Поскольку удаление разделения узлов потенциально может повлиять на существующие приложения, доступно значение реестра, позволяющее воздействовать на работу разделения устаревших узлов. Разделение узлов можно включить повторно, создав REG_DWORD значение с именем «сплитларженодес» со значением 1 под HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\NUMA. Чтобы изменения этого параметра вступили в силу, требуется перезагрузка.

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

В следующем примере сначала демонстрируются потенциальные проблемы с построением таблиц, сопоставленных процессорам с узлами NUMA с помощью устаревших API сходства, которые больше не предоставляют полный набор всех процессоров в системе. это может привести к созданию неполной таблицы. Последствия такой неполноты зависят от содержимого таблицы. Если в таблице просто хранится соответствующий номер узла, это, скорее всего, проблема с производительностью, если необнаруженные процессоры остаются в составе узла 0. Однако если таблица содержит указатели на структуру контекста для каждого узла, это может привести к ненулевым разыменованиям во время выполнения.

Далее в примере кода показаны два обходных решения проблемы. Первый заключается в переходе на многогрупповые интерфейсы API сходства узлов (пользовательский режим и режим ядра). Второй — использовать кекуерилогикалпроцессоррелатионшип для прямого запроса узла NUMA, связанного с данным номером процессора.

API NUMA

В следующей таблице описывается API NUMA.

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

Источник