Pull to refresh

Comments 11

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

Итого — идея достаточно дикая и как все это проверить на практике я не знаю.
На ESXi 4.1 и вин сервер 2003 прокатит?
чисто теоретически да, при всех 3 работающих условиях, но мне все равно не ясно как в той же 2003 увидеть NUMA статистику.
3-й пункт можно поподробнее. Спасибо.
Я имел в виду, что если мы хотим, чтобы NUMA scheduling происходил внутри ОС, а не внутри ESXi, то на уровне ESXi нам надо отключить NUMA Scheduler для этой VM, иначе у нас будут работать два NUMA Scheduler которые вполне возможно будут конфликтовать.

но мне кажется слишком много всяких «если».
А насколько падает производительность для Wide VM и имеет ли смысл городить ради этого огород?
Коллеги, я не замерял производительность, да и сложно вывести какую то общую цифру, которая наверняка будет зависеть от ОС, приложения, количества ВМ на хосте, количества 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 спровоцировал меня на достаточно нелепую идею
Коллеги, пожалуйста, аргументируйте минусы. Опыта в написании статей у меня почти нет и поэтому я всегда рад критике, которая помогает мне доносить материал более доступно.
Скорость работы WideVM в теории может упасть очень значительно — до 30%, но с выходом 4.1 VMware оптмизацию NUMA планировщика, чтобы уменьшить это значение. Теперь ESX 4.1 знает, что у него есть Wide VM, и старается по максимум её оптимизировать. VMware сообщает, что это 11-17% (реальных) по сравнению с 4.0.
Тут много нюансов, и всё же я бы рекомендовал стараться создавать ВМку не выходящую за пределы NUMA.
в VMware KB есть статья, описывающая ситуацию, при которой после миграции ВМ между серверами ESX NUMA может отрицательно влиять на производительность — kb.vmware.com/kb/2000740
сам не сталкивался, но может кому пригодится.
Only those users with full accounts are able to leave comments. Log in, please.