Будет установка VM больше чем с 1 CPU/, ядро на самом деле улучшают производительность?
Я использую rsnapshot для резервного копирования моих удаленных серверов. Это входит в систему каждой ночью от домашнего офиса, и копирует все, что изменяется в течение того дня. Это свет на пропускной способности и имеет маленький след. На проблеме, она только работает над подобными UNIX системами.
это зависит от того, что выполняет VM, гость на машине с n количеством ядер выполнит лучше всего в n-1 ядрах, присвоенных, пока гость способен к использованию нескольких центральных процессоров эффективно. К сожалению, самый простой способ определить это состоит в том, чтобы попробовать его и видеть. Я обычно запускаю с 2 и остановка, когда у меня заканчивается увеличение производительности. Обычно 2 ядра - то, где я вижу "зону наилучшего восприятия". Немного комбинаций приложения/OS, на которые я натыкался, масштабируются лучше, чем это.
Для разъяснения Вы говорите, что у Вас есть двухъядерный ЦП, и Вы присвоили 4 виртуальных центральных процессора на VM?
В этом случае, нет; при присвоении большего количества vCPUs, чем у Вас есть физические ядра выполнения, Вы будете на самом деле видеть небольшое сокращение производительности из-за издержек совместного использования 2 физических ядер среди 4 виртуальных ядер (плюс все работающее на физическом хосте).
Вы будете видеть лучшую производительность от VM путем присвоения ему 2 vCPUs.
Мы экспериментировали только что (см. мой вопрос по сравнению с предыдущим годом) с присвоением vCPUs от физических ядер по сравнению с логическими ядрами (потоки) в четырехъядерных центральных процессорах с гиперпоточностью (8 присваиваемых vCPUs, казалось, были доступны). Как ответы мне тогда предложили - и наш опыт подтвердил - необходимо выделить минимальное количество ядер, которые Вы можете каждому гостю, чтобы позволить этому выполнять.
Когда присвоение большего количества vCPUs, чем физические ядра, доступные на хосте, если гости являлись объектом одновременной гиперпоточности загрузки, было не всегда достаточно быстро при переключении контекста ЦП между потоками для эффективного моделирования другого ЦП. Это может привести к очень противному материалу для всех гостей, включая тупики и тайм-ауты, которые могут потребовать перезагрузки, fsck, и хуже на стеке. Даже если этого материала не произойдет, то производительность часто будет медленнее для гостей, а не быстрее.
Как @Chris S выразился в его комментарии тогда, "всегда выделяйте так мало, как можно сойти с рук, и Вы избежите больших головных болей".