Как лучше/быстрее выделять CPU?

Question

[synapse_people]

Как быстрее - задать в конфиге KVM список(номера) ядер для использования виртуалкой или указать просто общее количество виртуальных ядер в системе и пусть хост сам их выделяет как может?

Answer 1

[hint000]

В общем случае - указать количество ядер и пусть хост сам их выделяет. Это нормально.

В частном случае у вас могут быть какие-то хитрые нестандартные причины, чтобы отдавать фиксированные номера ядер. Тогда можно стартовать KVM через taskset. (Но количество ядер всё равно придётся указывать, помимо их номеров. Номера указываете в параметрах taskset, а количество в параметрах KVM - одно от другого не зависит.) В порядке теста я пробовал через taskset - да, работает, но особого смысла в этом не нашел. Отдельные процессы KVM всё равно по разным ядрам прыгают, в пределах выделенных. Так что смысл вижу только когда ровно одно ядро выделяется виртуалке, чтобы оно исполнялось всегда на одном и том же физическом ядре.

Comments

[synapse_people]

я почитал маны в интернете, советуют привязывать виртуалки к нума нодам.. Как считаете, есть смысл так делать? По мне, так это то, что я искал, т.к. система многопроцессорная
Как думаете, это нормальное решение?

[hint000]

synapse_people, для NUMA, возможно, есть смысл. Хотя... вот я глянул на свой хост:

$ sudo numastat -c qemu-

Per-node process memory usage (in MBs)
PID Node 0 Node 1 Total
--------------- ------ ------ -----
4778 (qemu-syste 76 16293 16368
6968 (qemu-syste 10804 1529 12333
14820 (qemu-syst 1039 8 1048

- это без привязки, и получается, что система сама вполне сносно распределила. Первая виртуалка на 99.5% на Node 1, вторая виртуалка на 87.6% на Node 0, третья виртуалка на 99.1% на Node 0.
И это при том, что у хоста uptime 299 дней, за это время виртуалки гасились и поднимались в разном порядке несколько раз. Т.е. по идее, без привязки можно было ожидать некоторый бардак в распределении по нодам (грубо говоря, около половины памяти на одной ноде и около половины на другой ноде по каждой виртуалке - вот это было бы совсем неоптимально). Но, как видим, бардак минимальный. Возможно, у вас будет по-другому, надо пробовать.

[synapse_people]

hint000, а вы можете привести пример XML конфига, который используете для вдсок?

[hint000]

synapse_people, у меня не совсем VDS, просто на предприятии кучка виртуальных машин крутится на чуть меньшей кучке разношерстных железок. Т.е. всё корпоративное - могу конфигурировать на свой вкус (ровно до тех пор, пока не прошу докупить чего-то нового, хе-хе).
Ну и я ретроград :) - без XML делаю, без libvirt, голым .sh скриптом. Прописываю в скрипте переменные, соответствующие параметрам виртуалки, а потом тупо команда запуска, в которой эти переменные подставлены. Ну там перед запуском ещё несколько проверок делается и вывод отладочной информации (по памяти, по образам дисков...).
В первом приближении - как в этой https://habr.com/ru/post/176823/ статье, в своё время она помогла мне с некоторыми моментами.

[hint000]

synapse_people, мой пример:

#!/bin/sh
VM_ID=17
VMNAME="vm_$VM_ID"
CPU="-cpu host -enable-kvm -smp 2,cores=2,threads=1,sockets=1"
MEM="-m 1G"
USBDEV1="HASP"
USBDEV2="Uninterruptible Power Supply"
USB1=$(lsusb|grep "$USBDEV1"|awk '{print $6}'); [ $USB1 ] && USB1="-usbdevice host:$USB1"
USB2=$(lsusb|grep "$USBDEV2"|awk '{print $6}'); [ $USB2 ] && USB2="-usbdevice host:$USB2"
USB3="-usbdevice tablet"
USB="-usb $USB1 $USB2 $USB3"
KVM_RESERVED="52:54:00"
MACBASE="$KVM_RESERVED:12:34"
MAC="$MACBASE:$VM_ID"
NETDEV="-netdev bridge,id=netdev-$VM_ID,br=virbr0"
NETNIC="-net nic,vlan=0,netdev=netdev-$VM_ID,macaddr=$MAC,model=virtio,name=guest-nic-$VM_ID"
NET="$NETDEV $NETNIC"
VIRTIO1="-balloon virtio"
VIRTIO2="-device virtio-serial"
VIRTIO3="-chardev socket,id=qga0,path=/tmp/qga.sock,server,nowait"
VIRTIO4="-device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0"
VIRTIO="$VIRTIO1 $VIRTIO2 $VIRTIO3 $VIRTIO4"
DIR1=/mnt/raid/$VMNAME
mount /mnt/raid

MONSOCKET="$DIR1/monitor"
[ ! -e $MONSOCKET.in ] && mkfifo $MONSOCKET.in
[ ! -e $MONSOCKET.out ] && mkfifo $MONSOCKET.out
MONITOR="-monitor pipe:$MONSOCKET"
VMPID="-pidfile $DIR1/pid"
VMLOG="-d unimp,guest_errors -D $DIR1/log"
VMUUID="-uuid `uuidgen -t`"
DISK1=$DIR1/dragon.qcow2
echo "\nDISK1=$DISK1"; [ $DISK1 ] && qemu-img check $DISK1
echo "\nDISK2=$DISK2"; [ $DISK2 ] && qemu-img check $DISK2
echo "\nDISK3=$DISK3"; [ $DISK3 ] && qemu-img check $DISK3
echo "\nDISK4=$DISK4"; [ $DISK4 ] && qemu-img check $DISK4
[ $DISK1 ] && DISK1="-drive file=$DISK1,if=virtio,media=disk,cache=writeback,aio=threads,index=0,werror=report,rerror=report,format=qcow2,discard=on"
[ $DISK4 ] && DISK4="-drive file=$DISK4,if=ide,media=cdrom"
[ $DISK4 ] || DISK4="-drive             if=ide,media=cdrom"
DISKS="$DISK1 $DISK2 $DISK3 $DISK4"
free
echo 0 > /sys/kernel/mm/ksm/run
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
echo "Starting VM $VMNAME $VMUUID..."
logger -t kvm-vms "Starting VM $VMNAME $VMUUID..."
/usr/bin/qemu-system-x86_64 \
-name $VMNAME \
$VMUUID \
$VMPID \
$VMLOG \
-rtc base=localtime \
-boot c \
$CPU \
$MEM \
$NET \
$USB \
$DISKS \
$VIRTIO \
$MONITOR \
-vnc :$VM_ID,lossy \
&

[synapse_people]

hint000, емое
Спасибо конечно, но я думал там libvirt)))
А как этот скрипт стартует с системой?

[hint000]

synapse_people, в /etc/rc.local запускается после того, как все системные сервисы стартанули

/mnt/raid/vm_20/qemu20.sh
sleep 10
/mnt/raid/vm_19/qemu19.sh

[synapse_people]

hint000, А у вас нет случайно сведений, можно ли вдску повесить строго на 1 нума-ноду и выдать ей только 1 планку физическую памяти? Вот сервер по 8 гб планки, сделать бы так
1 проц+1планка = 1 вдс
Было бы супер

[hint000]

synapse_people, Распределением памяти занимается ядро операционной системы. Теоретически можно взять исходники ядра Linux, потратить некоторое время (условно месяц... или два... если ни на что другое не отвлекаться) на изучение той части, которая рулит памятью, потом ещё (месяц или два) на внесение изменений и отладку - и можно добиться такого, чтобы ровно одну планку выделять, ну или ровно половину планки... Это теоретически. А практически это не имеет смысла, т.к. не добавит скорости (и даже наоборот - в 2-канальном или 4-канальном режиме скорость увеличивается за счет "размазывания" блока данных по нескольким планкам). И самое плохое - это создаст большие проблемы с безопасностью. Сейчас ядро рулит памятью "как-то там", для любого процесса за пределами ядра невозможно предсказать, где в адресном пространстве находятся блоки памяти другого процесса. Если процессы будут получать память по фиксированным адресам, то это сильно упростит жизнь злоумышленникам. Само по себе это не будет уязвимостью, но при наличии какой-то уязвимости может упростить взлом многократно.

Как повесить строго на одну NUMA ноду - написано по ссылке в моем первом комментарии (вот она https://ivirt-it.ru/qemu-kvm-and-numa/ ). Насколько я понимаю, строго на одну NUMA ноду получится в том случае, если на этой ноде имеется свободной памяти не меньше, чем хотим выделить виртуальной машине. Т.е. например: на хосте 16 Гб и две ноды, но в данный момент кое-что уже запущено и у нас на Node0 свободно 7 Гб и на Node1 свободно 5 Гб. Хотим запустить новую виртулку с 6 Гб памяти. Так вот, сейчас строго на Node0 мы её сможем повесить, а строго на Node1 не сможем. Т.е. если уж вручную привязывать к одной ноде, то надо заранее проверять, где сколько памяти свободно.