vmnomad Jul 6 2011 at 11:52

NUMA и что про него знает vSphere?

4 min

25K

Virtualization*

+17

Comments 11

Didjeru Jul 6 2011 at 12:49

Я правильно понимаю: если на сервере 8 ядер и 8 гб. оперативы, то например при 4 vCPU на двух VM лучше не отдавать одной VM более 4 гб. памяти, а то и менее, ведь ESXi тоже хочется оперативки? Они ведь попадают в один numa узел только в таком случае?

vmnomad Jul 6 2011 at 13:09

Если у вас 2 физических CPU с 4 ядрами на каждом, то все верно.

Правда мне сейчас пришла в голову мысль маловероятная, но все же. в vSphere по умолчанию есть каждый vcpu равен одному ядру. То есть 8 vcpu будут равны восьми cores. В то же время есть возможность изменять эту пропорцию, например, когда у вас по ОС лицензии ограничено количество поддерживаемых cpu. То есть в нашем случае можно будет изменить значение cpuid.coresPerSocket и сделать его равным 4. Тогда ваша VM будет видеть 2 vCPU и каждый будет с 4 cores. Ну и пусть тогда распределение между NUMA узлами происходит на уровне Guest OS.
Но сие возможно как минимум при трех условиях:
1. 4 vCores каждого vCPU вашей VM всегда будут исполняться на одном и том же физическом CPU. То есть 100% соответствие между виртуальными CPU/Cores и физическими.
2. Guest OS будет знать про NUMA архитектуру
3. Все это не будет вступать в конфликт с логикой NUMA scheduler

Итого — идея достаточно дикая и как все это проверить на практике я не знаю.

Didjeru Jul 6 2011 at 13:18

На ESXi 4.1 и вин сервер 2003 прокатит?

vmnomad Jul 6 2011 at 13:21

чисто теоретически да, при всех 3 работающих условиях, но мне все равно не ясно как в той же 2003 увидеть NUMA статистику.

Didjeru Jul 6 2011 at 13:36

3-й пункт можно поподробнее. Спасибо.

vmnomad Jul 6 2011 at 13:48

Я имел в виду, что если мы хотим, чтобы NUMA scheduling происходил внутри ОС, а не внутри ESXi, то на уровне ESXi нам надо отключить NUMA Scheduler для этой VM, иначе у нас будут работать два NUMA Scheduler которые вполне возможно будут конфликтовать.

но мне кажется слишком много всяких «если».

omnimod Jul 6 2011 at 14:23

А насколько падает производительность для Wide VM и имеет ли смысл городить ради этого огород?

vmnomad Jul 6 2011 at 14:39

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

Но сама vmware дает следующую информацию «Performance benefit depends on the workload and configuration. Internal studies based on SPECjbb, a server Java workload, show up
to 7% performance improvement.» — смотреть тут.

Но Wide VM работает по умолчанию и не требует городить огород. просто вопрос коллеги Didjeru спровоцировал меня на достаточно нелепую идею

vmnomad Jul 6 2011 at 18:09

Коллеги, пожалуйста, аргументируйте минусы. Опыта в написании статей у меня почти нет и поэтому я всегда рад критике, которая помогает мне доносить материал более доступно.

ZloyKakPes Jul 6 2011 at 18:37

Скорость работы WideVM в теории может упасть очень значительно — до 30%, но с выходом 4.1 VMware оптмизацию NUMA планировщика, чтобы уменьшить это значение. Теперь ESX 4.1 знает, что у него есть Wide VM, и старается по максимум её оптимизировать. VMware сообщает, что это 11-17% (реальных) по сравнению с 4.0.
Тут много нюансов, и всё же я бы рекомендовал стараться создавать ВМку не выходящую за пределы NUMA.

argo2003 Jul 6 2011 at 20:46

в VMware KB есть статья, описывающая ситуацию, при которой после миграции ВМ между серверами ESX NUMA может отрицательно влиять на производительность — kb.vmware.com/kb/2000740
сам не сталкивался, но может кому пригодится.