У нас есть хост-система KVM на Ubuntu 9.10 с более новым четырехъядерным процессором Xeon с гиперпоточностью. Как подробно описано на Страница продукта Intel, процессор имеет 4 ядра, но 8 потоков. / proc / cpuinfo и htop оба перечисляют 8 процессоров, хотя каждый указывает 4 ядра в cpuinfo. KVM / QEMU также сообщает о 8 виртуальных ЦП, доступных для назначения гостям.
У меня вопрос: когда я выделяю виртуальные ЦП гостевым виртуальным машинам, следует ли выделять их по ядрам или по потокам? Поскольку KVM / QEMU сообщает, что у сервера есть 8 виртуальных ЦП для распределения, следует ли мне настроить гостя на использование 4 ЦП, тогда как раньше я бы установил его на использование 2 (при условии, что всего доступно 4 ЦП)? Я хотел бы получить максимальную отдачу от оборудования хоста без чрезмерного выделения ресурсов.
Обновить: Ответ Chopper3, несомненно, правильный. Тем не менее, я все еще хотел бы услышать от экспертов по аппаратному обеспечению, которые могли бы разъяснить аспекты производительности потоков по сравнению с ядрами ... кого угодно?
Установите минимальное количество виртуальных ЦП, необходимое вашим серверам для выполнения своих функций, не выделяйте их слишком много, иначе вы легко можете помедленнее ваши виртуальные машины.
Это довольно сложно. В зависимости от нагрузки HT может увеличить производительность примерно на 30% или снизить ее. Обычно я советую не выделять больше виртуальных ЦП, чем у вас есть физических ядер, для одной виртуальной машины, но если виртуальная машина довольно простаивает (и, конечно, такая виртуальная машина не требует слишком много процессоров), ее можно передать как много виртуальных ЦП, поскольку у вас есть потоки. Вы действительно не хотите давать одной виртуальной машине больше vCPU, чем у вас планируемые ядра вот что я к чему. И в любом случае совет @ Chopper3 верен - не давайте виртуальной машине больше v-CPU, чем ей абсолютно необходимо.
Итак, в зависимости от того, насколько загружены и критичны ваши виртуальные машины, вы либо вообще не превышаете доступность, либо придерживаетесь количества физических ядер, либо увеличиваете количество потоков на каждую виртуальную машину.
Теперь, переходя к вопросу о HT, это, как правило, полезно, особенно когда вы передаете больше виртуальных ЦП на свои виртуальные машины, чем у вас есть физические ядра или даже потоки, потому что это упрощает планировщику Linux планирование этих виртуальных ЦП.
И последнее: с kvm виртуальный ЦП, назначенный виртуальной машине, - это просто процесс на хосте, запланированный планировщиком Linux, поэтому все обычные оптимизации, которые вы можете здесь сделать, легко применимы. Более того, настройка ядер / сокетов - это просто способ, которым этот процесс будет отображаться для гостевой ОС виртуальной машины, на хосте это все еще просто процесс, независимо от того, как виртуальная машина его видит.
Как правило, HT хорошо работает с рабочими нагрузками, которые больше связаны с вводом-выводом - ЦП может запланировать больше задач обработки из очереди другого виртуального ЦП, в то время как первый виртуальный ЦП ожидает ввода-вывода. На самом деле все подсистемы HT предоставляют вам аппаратное ускорение переключения контекста - это шаблон рабочей нагрузки, который также используется при переключении между виртуальными машинами. Итак, HT (обычно) немного снижает замедление, когда у вас больше виртуальных машин, чем ядер, при условии, что каждая виртуальная машина получает одно виртуальное ядро.
Назначение нескольких виртуальных ЦП для виртуальной машины может повысить производительность, если приложения в виртуальной машине написаны для потоковой передачи, но это также усложняет жизнь гипервизору; он должен распределять время на 2 или 4 ЦП одновременно, поэтому, если у вас есть четырехъядерный ЦП и виртуальная машина с четырьмя виртуальными ЦП, только одна виртуальная машина может быть запланирована в течение этого временного интервала (тогда как она может запускать 4 разных виртуальных машины с одним виртуальным ЦП) однажды).
Я думаю уточнить ответ Chopper3: если системы в основном простаивают по процессору, не назначайте кучу виртуальных ЦП, если они интенсивно используют ЦП, будьте очень осторожны, чтобы не перераспределить. Вы должны иметь возможность выделить в общей сложности 8 виртуальных ЦП без конфликтов. Вы можете перераспределить доступ, но если вы это сделаете, убедитесь, что ни у одного гостя, особенно у гостя, интенсивно использующего ЦП, нет 8 виртуальных ЦП, иначе возникнет конфликт. Я не знаю, чтобы механизм планировщика KVM был более конкретным, чем это.
Вышеизложенное основано на следующем понимании vCPU по сравнению с закрепленным процессором, а также на предположении, что KVM позволит одному гостю (или нескольким гостям) отвлекать весь фактический процессор от других, если вы выделите ему (/ им) достаточно потоков. vCPU ~ поток хоста, гостевой ЦП ЦП = ядро хоста, гостевой ЦП (я не играл со смешанным виртуальным ЦП и закрепленным ЦП на одном гостевом компьютере, потому что у меня нет Hyperthreading.)