Виртуализация: закрепление vCPU с помощью Hyperthreading Host CPU?

Виртуализация: закрепление vCPU с помощью Hyperthreading Host CPU?

Я использую KVM/libvirt на сервере Linux с процессором Core i7-2600, который имеет следующую топологию процессора (1 сокет, 4 ядра, 8 потоков):

Physical | Logical
---------+--------
Core 0   | 0, 4
Core 1   | 1, 5
Core 2   | 2, 6
Core 3   | 3, 7

Обычно я запускаю 3 виртуальные машины на этом хосте, каждая с 2 виртуальными ЦП. Чтобы улучшить производительность, сохраняя кэши горячими, я хотел бы прикрепить vCores виртуальных машин к фиксированным ядрам хоста.

Теперь возникает вопрос о сопоставлении ядер виртуальной машины с ядрами хоста, учитывая тот факт, что процессор хоста использует технологию Hyperthreading:

Вариант 1: Одна виртуальная машина на каждое физическое ядро ​​хоста

VM1: logical cores 1, 5
VM2: logical cores 2, 6
VM3: logical cores 3, 7

Таким образом, два виртуальных ядра виртуальной машины будут сопоставлены с родственными гиперпотоками на хост-процессоре. Гостевой код выиграет от локальности кэша, поскольку два хост-ядра разделяют некоторые кэши.

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

Вариант 2: Распределенные ядра виртуальных машин

VM1: logical cores 1, 2
VM2: logical cores 3, 5
VM3: logical cores 6, 7

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

На всех виртуальных машинах в основном работают веб-сервисы (Nginx, MySQL, PHP-FPM), поэтому я понимаю, что вопрос носит скорее теоретический характер, но все же мне хотелось бы знать.

решение1

Возможно, вы слишком много об этом думаете.

Ручное назначение ядер здесь может фактически привести к снижению производительности. В мире VMware мы не делаем этого, если нет очень конкретных требований, но для рабочей нагрузки и приложений, которые вы описали, это не обязательно. Позвольте KVM планировать дела и делать их. Если сомневаетесь, купите больше ядер и сокетов. Но ЦП не будет ограничивающим фактором в таком небольшом развертывании.

решение2

Вариант 1 не должен замедлять работу в большинстве случаев, но ОС и программы могут стать слишком активными из-за своих рабочих нагрузок. Это может навалиться. Я думаю, вариант 2 лучше, если ваш сосед не против ~крошечного~ замедления.

Связанный контент