Коллеги, я не замерял производительность, да и сложно вывести какую то общую цифру, которая наверняка будет зависеть от ОС, приложения, количества ВМ на хосте, количества 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 спровоцировал меня на достаточно нелепую идею
Я имел в виду, что если мы хотим, чтобы NUMA scheduling происходил внутри ОС, а не внутри ESXi, то на уровне ESXi нам надо отключить NUMA Scheduler для этой VM, иначе у нас будут работать два NUMA Scheduler которые вполне возможно будут конфликтовать.
Если у вас 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
Итого — идея достаточно дикая и как все это проверить на практике я не знаю.
Коллеги, я понимаю это не совсем вежливо, но я тут начал переводить другие свои статьи и понял, что опубликовать я их не могу пока карма не подрастет до 5. Вы не могли бы мне ее подкачать? Я понимаю, что есть и стандартные пути через «вопросы и ответы», но у меня совсем не на это свободного времени. Собственно мне выше 5 не надо, не кармы ради, а всеобщего блага для :)
Хороший вопрос, но я не знаю на него 100% правильный ответ. Постараюсь копнуть в эту сторону, но пока у меня только логическая догадка, что TPS побитовое сравнение все таки будет делать только тогда, когда будет достигнут high state. Для него это ведь всего лишь подсказки — hints :)
спасибо за вопрос.
к тому же те инструменты используемые 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 спровоцировал меня на достаточно нелепую идею
но мне кажется слишком много всяких «если».
Правда мне сейчас пришла в голову мысль маловероятная, но все же. в 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
Итого — идея достаточно дикая и как все это проверить на практике я не знаю.
спасибо за вопрос.