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

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

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

Значит ли это, что вы не должны создавать больших ВМ? Нет, если ВМ действительно требует большой вычислительной мощности. Причина, по которой я пишу это - большинство IT отделов руководствуются одной и той же политикой и для физических и для виртуальных машин. ВМ дают множество процессоров и кучу памяти на случай если вдруг это когда-либо потребуется в будущем. И хотя этот подход экономит время и позволяет не ввзяываться в офисную политику, для больших ВМ он может вылиться в ненужные задержки. И вот почему:

Узел NUMA

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



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

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

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

ESX является NUMA aware, т.е. знает, что работает на NUMA системе, и соотв. будет применять специализированный NUMA планировщик CPU. На обычных, не-NUMA системах, планировщик ESX разпределяет нагрузку между всеми сокетами в режиме "round-robin". Этот подход ведет к увеличению производительности, поскольку задействуется максимальный объем кэша. Каждый процессор vSMP машины при этом размещается на следующем сокете.
Но на NUMA системе включается в работу совершенно иной планировщик, использующий оптимизацию под NUMA систему - а именно размещение ВМ целиком на одном NUMA узле, и виртуальные процессоры и память. Это гарантирует нам максимально возможную "локальность" памяти.



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



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

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

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

Отлично, все vCPU поместились в один узел NUMA, но если у ВМ памяти больше, чем локальной памяти узла? Неправильная конфигурация размера памяти ВМ приведет к тому, что планировщик не сможет использовать оптимизацию для это ВМ, и ее память будет разбросана по всему серверу.
Так как же можно узнать, сколько памяти установлено на каждом NUMA узле? Обычно для каждого процессора (сокета) устанавливают одинаковое количество памяти, и соотв. доступная физическая память (минус память сервис-консоли) делится между сокетами. Например, по 16GB памяти на каждый сокет для двухпроцессорной (2-сокетной) системы с 32GB памяти. Быстрый способ уточнить конфигурацию памяти в NUMA системе - esxtop. Esxtop будет показывать статистику NUMA только при работе на NUMA системе. Первое число указывает на объем памяти, управляемый ESX на данном NUMA узле, а в круглых скобках мы видим объем свободной памяти на данном узле.



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

Давайте поисследуем немного NUMA статистику esxtop. Данная система - HP BL460c с двумя 4-ядерными процессорами Nehalem и 64GB памяти. Как видно, у каждого NUMA узла примерно по 32GB. На первом узле свободно 13GB, а на втором всего 372MB - видимо память скоро совсем закончится, но, к счастью, ВМ на этом узле все же могут обращаться к удаленной памяти. Когда у ВМ определенная часть памяти становится удаленной, планировщик перемещает ВМ на другой узел, чтобы увеличить степень локальности памяти. Нигде в документации не указано, какая именно степень локальности требуется, чтобы началась миграция, но плохой локальностью считается ситуация, когда 80% памяти ВМ размещено в локальной памяти. Поэтому было бы разумно предположить, что миграция произойдет при падении локальности ниже 80%. Esxtop может показать NUMA статистику памяти для каждой ВМ: запустите esxtop, нажмите m для статистики памяти, затем f для изменения отображаемой статистики, и еще раз f для выбора статистики NUMA.



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

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



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

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

Metric Explanation
NHN Current Home Node for virtual machine
NMIG Number of NUMA migrations between two snapshots. It includes balance migration, inter-mode VM swaps performed for locality balancing and load balancing
NRMEM (MB) Current amount of remote memory being accessed by VM
NLMEM (MB) Current amount of local memory being accessed by VM
N%L Current percentage memory being accessed by VM that is local
GST_NDx (MB) The guest memory being allocated for VM on NUMA node x. “x” is the node number
OVD_NDx (MB) The VMM overhead memory being allocated for VM on NUMA node x

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

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



Figure 7: NUMA TPS boundaries

Данное поведение можно изменить через параметр VMkernel.Boot.sharePerNode. Но как и большинство параметров по умолчанию в ESX, этот параметр стоит изменять только если вы абсолютно уверены, что для вашей среды это принесет преимущества. В 99,99% сред наилучший вариант - оставить настройку по умолчанию.

Оригинал: Frank Denneman

Комментариев нет:

Отправить комментарий