Виртуализированные ядра процессора и потоки

У нас есть хост-система KVM в Ubuntu 9.10 с новым четырехъядерным процессором Xeon с гиперпоточностью. Как подробно описано на странице продуктов Intel , процессор имеет 4 ядра, но 8 потоков. В / proc / cpuinfo и htop перечислены 8 процессоров, хотя каждый из них содержит 4 ядра в cpuinfo. KVM / QEMU также сообщает о 8 VCPU, доступных для назначения гостям.

Мой вопрос заключается в том, когда я выделяю VCPU для гостей виртуальных машин, я должен выделить для каждого ядра или для потока? Так как KVM / QEMU сообщает, что сервер имеет 8 VCPU для распределения, я должен идти вперед и настроить гостя на использование 4 CPU, где я ранее установил бы его использование 2 (предполагая, что доступно 4 VCPU всего)? Я хотел бы получить максимум возможного от аппаратного обеспечения хоста без перерасхода.

Обновление: ответ Chopper3, несомненно, правильный подход. Тем не менее, я все еще хотел бы услышать от любых экспертов по аппаратному обеспечению, которые могли бы объяснить аспекты производительности потоков против ядер ... кто-нибудь?

Установите наименьшее количество виртуальных ЦП, которые необходимы вашим серверам для выполнения своих функций, не перераспределяйте их, иначе вы можете легко замедлить работу своих виртуальных машин.

Как правило, HT хорошо работает с рабочими нагрузками, которые тяжелее при вводе-выводе - ЦП может планировать выполнение большего количества задач обработки из очереди другого виртуального ЦП, пока первый виртуальный ЦП ожидает ввода-вывода. На самом деле все подсистемы HT дают вам аппаратное переключение контекста - это шаблон рабочей нагрузки, который также используется при переключении между виртуальными машинами. Таким образом, HT (обычно) немного уменьшает замедление, когда у вас больше виртуальных машин, чем ядер, при условии, что каждая виртуальная машина получает одно виртуальное ядро.

Назначение нескольких виртуальных ЦП виртуальной машине может повысить производительность, если приложения в виртуальной машине написаны для многопоточности, но это также усложняет жизнь гипервизору; он должен распределять время на 2 или 4 ЦП одновременно - поэтому, если у вас есть четырехъядерный ЦП и виртуальная машина с четырьмя виртуальными ЦПУ, во время этого временного интервала может быть запланирована только одна виртуальная машина (тогда как она может запускать 4 разные виртуальные машины с одним виртуальным ЦП сразу).

Это довольно сложно. В зависимости от нагрузки HT может увеличить производительность на ~ 30% или уменьшить ее. Обычно я советую не выделять больше виртуальных ЦП, чем у вас физических ядер, одной виртуальной машине, но если виртуальная машина довольно простаивает (и, конечно, такая виртуальная машина на самом деле не потребует слишком много процессорных процессоров), она может быть выделена как много виртуальных ЦП, поскольку у вас есть темы. Вы на самом деле не хотите, чтобы у одной виртуальной машины было больше виртуальных ЦП, чем у планируемых ядер - вот что я имею в виду . И в любом случае совет @ Chopper3 верен - не давайте ВМ больше v-CPU, чем это абсолютно необходимо.

Таким образом, в зависимости от того, насколько загружены и критичны ваши виртуальные машины, вы либо не перераспределяете их вообще, либо используете физическое ядро, либо достигаете такого же количества потоков, что и виртуальная машина.

Теперь, говоря о HT, это, как правило, полезно иметь, особенно когда вы выделяете больше виртуальных ЦП на свои виртуальные машины, чем физические ядра или даже потоки, потому что планировщику Linux легче планировать эти виртуальные ЦП.

И последнее: kvm, vCPU, назначенный виртуальной машине, - это просто процесс на хосте, запланированный планировщиком Linux, поэтому все обычные оптимизации, которые вы можете здесь выполнить, легко применяются. Более того, настройка ядер / сокетов - это просто способ отображения этого процесса для гостевой ОС виртуальной машины, а на хосте - это просто процесс, независимо от того, как его видит виртуальная машина.

Я думаю подробно остановиться на ответе Chopper3: если системы в основном не заняты процессором, не назначайте связку vcpu, если они интенсивно работают с процессором, будьте очень осторожны, чтобы не перераспределить. Вы должны иметь возможность выделить в общей сложности 8 виртуальных ЦП без конкуренции. Вы можете перераспределить, но если вы это сделаете, убедитесь, что ни у одного гостя, особенно у гостя, интенсивно использующего процессор, нет 8 виртуальных процессоров, иначе у вас будет конфликт. Я не знаю механизм планировщика KVM, чтобы быть более конкретным, чем это.

Вышесказанное основано на следующем понимании vCPU по сравнению с закрепленным ЦП, а также на предположении, что KVM позволит одному гостю (или нескольким гостям) захватывать весь фактический ЦП от других, если вы выделите ему (/ им) достаточное количество потоков. vCPU ~ хост-поток, гостевой процессор CPU = хост-ядро, гостевой процессор (не играл со смешанным vCPU и закрепленным процессором на одном госте, потому что у меня нет Hyperthreading.)