kvm и количество ядер.

Минимум одно оставить хосту.

Лучше взять вторую «Железку с 20ю ядрами» и забыть как страшный сон про «вирт. машины» ибо эта технология не про производительность о которой Вы спрашиваете.

Логично. А в остальном, есть ли разница?

Попробовать поставить мониторинг на наслоение загрузку io и проца
1. Одновременная работа загрузки процов (потоков)
2. Загруженность IO (ввод вывод дисков переферии)
3. Переодичность запуска (загрузки), длительность выполнения
Если хватает и сильно не пересекается то 20-2(1 хост + 1 ну так чтоб было)=18 то можно и по 18 на одну kvm.
От себя. Было дело виртуалки не сильно кушали сами по себе, но в один момент могли запустится и проблема была в IO а не в процах. Ограничили по пропускной способности IO не помогло (ну точней не сильно, одна тормозила другая летала, а потом наоборот и все по кругу).
Попробуй поиграться если есть возможность, перенести cron (или его подобие) на разные промежутки времени.

Ответ выражается в вопросе - тебе надо гарантировать ресурсы или нет? Если надо - то 2x10. Если нет - 2x18, как уже посоветовали выше

В каждой машине, в любой момент может быть загружено 3 ядра по полной, остальные немного. - Если всем отдать по максимуму ядер, гиппервизор точно не допустит ситуации что все ядра будут недогружены, тогда, как именно на этих нагруженных ядрах случится так, что они будут делить одно и тоже ядро на железе? Гипертрейдинг лушче убрать в моём случае?

при совместном исп. ядер в разных вирт. машинах появляется «бесполезная» трата ресурсов на переключение контекста. В esx доходило до 50% трат всех СРU на перекл., а не на работу. После норм. распределения CPU тормоза прекратились

Если в каждой вм грузятся на 100% 3 ядра, имеет смысл забиндить реальные 6 ядер по 3 на каждую вм, а остальными пусть рулит kvm как ему хочется.

По НТ ничего не скажу.
Давно не видел тестов на эту тему.
У меня НТ включён.

В Интернет пишут, что биндить, типа не надо ничего… Ну и опять-же, а как биндить? :) Что бы забиндить на реальные ядра, а не на HT

А что подразумевается под «норм. распределением»..?

это называется cpupin, и в интернете его советуют использовать для повышения производительности

В такой ситуации если у тебя не NUMA то можно делать «жирные» виртуалки, благо vCPU-потоки шедулятся гипервизором вполне адекватно. Но если кто-то внезапно решит «поработать» - второй будет страдать.

отдавайте виртуалкам всё, сколько есть. -smp $(nproc) и пусть система сама решает кому чего.

вы просто ещё не знаете как хостинги оверселлят CPU, им реально пофигу что два клиента могут делить одно ядро между собой. за то клиенты несут бабки. хостеры не могут оверселлить RAM, HDD, но CPU — только так.

к вопросу о производительности. у меня в распоряжении HP ProLiant DL360 Gen9 [2x 2690v4, 320GB (10x 32GB 2133), H240ar (HBA), 1x SATA SSD 250GB].

мой любимый бенчмарк сборки ядра Linux, на хост-системе

real    2m21.894s
user    80m58.909s
sys     6m31.161s

на виртуалке на том же SSD, с тем же количеством ядер

real    2m57.927s
user    98m2.548s
sys     9m50.712s

разница ну пусть 40 секунд.

ну типа вообще пофигу.

плюсы и удобство виртуалки всё равно перевешивают недостачу производительности.

пининг нужен когда стоит задача изолировать ВМ от влияния друг на друга. Если такой задачи не стоит и ВМ «адекватны» то пининг будет нерезультативен. Линуксовый шедулер вполне справляется с тем чтобы по возможности не перебрасывать треды между ядрами если это возможно

хостеры не могут оверселлить RAM, HDD

Могут

Это потому что в esx идёт gang scheduling, KVM никогда этим не страдал

И?

В kvm нет накладных расходов на shared CPU по-сравнению с Pinned CPU?

В моём случае нагрузка имеет очень скачкообразный характер… - Было 0%, стало: 100%, потом 10%, через секунду: 100% и т.д.

Логика простая:

1. если раздать 10 первой и 9 второй то точно будет работать. Притом предсказуемо и повторяемо по производительности.
2. если не раздавать принудительно ничего, то бОльшую часть времени (если у тебя время 100% нагрузки на обеих виртуалках меньше половины) будет работать быстрее. Насколько быстрее зависит от того насколько эффективно может задача получить профит от 18 ядер вместо 10/9.
   Меньшую часть времени (когда обе виртуалки будут загружены больше чем на 50%) все будет работать медленнее. Насколько медленнее - зависит от эффективности шедулера

Имхо - выбор весьма очевиден - пойти по плану 1), оценить сильно ли не хватает производительности в пиках. Если хватает - ничего не трогать, если не хватает то понять что план 2) не гарантирует повышения производительности в пиках ибо пиковые нагрузки могут наступить на обеих вм одновременно -> Добавить ядер.

Спасибо!