У меня есть два сервера ProxMox, и когда я переместил одну из своих виртуальных машин, у меня возникли проблемы с производительностью.
ProxMox 3.4 работает на Intel Xeon E5606 (2 процессора, 4 ядра каждый, @ 2,13 ГГц). ProxMox 4.1 на Intel Xeon E5-2650L v3 (2 CPUS, 24 ядра каждый, @ 1,8 ГГц)
Я переместил две виртуальные машины с сервера 3.4 на сервер 4.1 (я сделал резервную копию на 3.4, восстановление на 4.1).
Кажется, что VM 816 работает примерно так же, но VM 814 сильно пострадала от производительности (теперь загрузка занимает 4-6 минут).
Интересное о них:
Очевидно, сразу видно различие в том, что один - ide, а другой - virtio. Но они были именно такими на старом сервере - почему он намного медленнее на новом сервере? Я пытался переключить 814 на virtio, но потом он не загружается.
Наиболее важно выяснить, связано ли это с более новой версией KVM на ProxMox 4.1. Я планирую обновить старый сервер до последней версии proxmox, но если это сломает мои виртуальные машины, это будет проблемой.
uname -a из ВМ 814: Linux SWBuild-Fedora.moberg 2.6.18-1.2798.fc6 # 1 SMP Mon Oct 16 14:54:20 EDT 2006 i686 i686 i386 GNU / Linux
uname -a из ВМ 816: Linux SWBuild-CentOS 2.6.32-71.el6.i686 # 1 SMP Пт, 12 ноября, 04:17:17 по Гринвичу 2010 г. i686 i686 i386 GNU / Linux
KVM-линии, полученные из ps:
/ usr / bin / kvm -id 814 -chardev socket, id = qmp, path = / var / run / qemu-server / 814.qmp, server, nowait -mon chardev = qmp, mode = control -vnc unix: / var /run/qemu-server/814.vnc,x509,password -pidfile /var/run/qemu-server/814.pid -daemonize -smbios type = 1, uuid = 709a3672-bb7e-40a8-9815-69129f612924 -name SWBuild -Fedora -smp 1, sockets = 1, cores = 1, maxcpus = 1 -nodefaults -boot menu = on, strict = on, reboot-timeout = 1000 -vga cirrus -cpu coreduo, + kvm_pv_unhalt, + kvm_pv_eoi, enforce -m 512 -k en-us -device pci-bridge, id = pci.1 ,ssis_nr = 1, bus = pci.0, addr = 0x1e -device pci-bridge, id = pci.2 ,ssis_nr = 2, bus = pci .0, addr = 0x1f -device piix3-usb-uhci, id = uhci, bus = pci.0, addr = 0x1.0x2 -device virtio-balloon-pci, id = balloon0, bus = pci.0, addr = 0x3 -iscsi имя-инициатора = iqn.1993-08.org.debian: 01: 1a1a811322d -drive file = / var / lib / vz / images / 814 / vm-814-disk-1.raw, if = none, id = drive-ide0, format = raw, cache = none, aio = native, detect-zeroes = on -device ide-hd, bus = ide.0, unit = 0, drive = drive-ide0, id = ide0, bootindex = 100 -drive, если = none, id = drive-ide2, media = cdrom, aio = thread -device ide-cd, bus = ide.1, unit = 0, drive = drive-ide2, id = ide2, bootindex = 200 -netdev type = tap, id = net0, ifname = tap814i0, script = / var / lib / qemu-server / pve-bridge, downscript = / var / lib / qemu-server / pve-bridgedown -device e1000, mac = 7A: 9F: 7F: 7C: 08: BA, netdev = net0, bus = pci .0, адрес = 0x12, id = net0
/ usr / bin / kvm -id 816 -chardev socket, id = qmp, path = / var / run / qemu-server / 816.qmp, server, nowait -mon chardev = qmp, mode = control -vnc unix: / var /run/qemu-server/816.vnc,x509,password -pidfile /var/run/qemu-server/816.pid -daemonize -smbios type = 1, uuid = 06458c85-061e-4783-9152-e0d7f8a9685d -name SWBuild -CentOS -smp 1, sockets = 1, cores = 1, maxcpus = 1 -nodefaults -boot menu = on, strict = on, reboot-timeout = 1000 -vga cirrus -cpu coreduo, + kvm_pv_unhalt, + kvm_pv_eoi, enforce -m 512 -k en-us -device pci-bridge, id = pci.1 ,ssis_nr = 1, bus = pci.0, addr = 0x1e -device pci-bridge, id = pci.2 ,ssis_nr = 2, bus = pci .0, addr = 0x1f -device piix3-usb-uhci, id = uhci, bus = pci.0, addr = 0x1.0x2 -device virtio-balloon-pci, id = balloon0, bus = pci.0, addr = 0x3 -iscsi имя-инициатора = iqn.1993-08.org.debian: 01: 1a1a811322d -drive file = / var / lib / vz / images / 816 / vm-816-disk-1.raw, if = none, id = drive-virtio0, format = raw, cache = none, aio = native, detect-zeroes = on -device virtio-blk-pci, drive = drive-virtio0, id = virtio0, bus = pci.0, addr = 0xa, bootindex = 100 -привод, если = нет, id = привод e-ide2, media = cdrom, aio = thread -device ide-cd, bus = ide.1, unit = 0, drive = drive-ide2, id = ide2, bootindex = 200 -netdev type = tap, id = net0, ifname = tap816i0, script = / var / lib / qemu-server / pve-bridge, downscript = / var / lib / qemu-server / pve-bridgedown -device e1000, mac = F6: CE: EE: 91: 65: 2B , netdev = net0, bus = pci.0, addr = 0x12, id = net0, bootindex = 300
ПРИМЕЧАНИЯ. Смена ОС на 814 на самом деле не вариант - эта виртуальная машина была построена из образа, взятого с реального оборудования, чтобы мы могли его сохранить. Он используется для сборки некоторых из наших старых систем, и у нас действительно нет времени на проверку модифицированной системы сборки.
ОБНОВЛЕНИЕ: Вероятно, корень проблемы заключается в различиях в картах RAID на двух серверах. При проектировании нового сервера другой администратор вспомнил, что у нас НЕ был флэш-модуль для карты RAID, поэтому мы аналогичным образом разработали новый сервер.
Дальнейшее расследование показывает, что у нас ДЕЙСТВИТЕЛЬНО есть флэш-модуль на старом сервере и он ЯВЛЯЕТСЯ активным, обеспечивая кэширование записи. Это, в сочетании с различными шаблонами доступа, вероятно, является корнем разницы в производительности.
Я действительно не понимаю, почему виртуальная машина ведет себя неправильно, но я обнаружил, что если я включил кеширование с обратной записью для этой виртуальной машины, она будет вести себя нормально.