+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Ужасно медленное полное клонирование виртуальной машины на Proxmox VE 5.1 с ZFS ZVOL, Proxmox Виртуальная Среда

chrone

Guest

25.01.2018 11:14:00

Используя последнюю версию Proxmox VE 5.1.x и ZFS RAID1 ZVOL на 8-ядерном процессоре и 16 ГБ ОЗУ, полное клонирование оффлайн ВМ очень медленное, даже когда процент загрузки ЦП %wa и нагрузка в среднем ниже 11% и 8 соответственно. Это связано с новыми патчами ядра для уязвимостей Meltdown и Spectre, несовместимыми с ZFS и конвертацией образов qemu? Я также заметил, что интерфейс Proxmox зависал до завершения восстановления ВМ из резервной копии vzdump на более мощном сервере без запущенных ВМ и на ZFS RAID1 ZVOL на SSD Intel DC S3500. Код: proxmox-ve: 5.1-36 (работающее ядро: 4.13.13-4-pve) pve-manager: 5.1-43 (работающая версия: 5.1-43/bdb08029) pve-kernel-4.4.98-3-pve: 4.4.98-103 pve-kernel-4.13.13-4-pve: 4.13.13-35 pve-kernel-4.4.19-1-pve: 4.4.19-66 pve-kernel-4.13.13-5-pve: 4.13.13-36 libpve-http-server-perl: 2.0-8 lvm2: 2.02.168-pve6 corosync: 2.4.2-pve3 libqb0: 1.0.1-1 pve-cluster: 5.0-19 qemu-server: 5.0-20 pve-firmware: 2.0-3 libpve-common-perl: 5.0-25 libpve-guest-common-perl: 2.0-14 libpve-access-control: 5.0-7 libpve-storage-perl: 5.0-17 pve-libspice-server1: 0.12.8-3 vncterm: 1.5-3 pve-docs: 5.1-16 pve-qemu-kvm: 2.9.1-6 pve-container: 2.0-18 pve-firewall: 3.0-5 pve-ha-manager: 2.0-4 ksm-control-daemon: 1.2-2 glusterfs-client: 3.8.8-1 lxc-pve: 2.1.1-2 lxcfs: 2.0.8-1 criu: 2.11.1-1~bpo90 novnc-pve: 0.6-4 smartmontools: 6.5+svn4324-1 zfsutils-linux: 0.7.3-pve1~bpo9

chrone

Guest

22.02.2018 14:07:00

Привет, Альвин, есть ли баг-репорт, за которым я мог бы следить по этой проблеме? Я столкнулся с подобным замедлением при полной клонировании шаблона размером 100 ГБ на ZFS ZVOL. "qemu-img convert" использовал всю память (буферизованную) и вызывал общее замедление системы. В моей системе только 64 ГБ оперативной памяти, и её не хватило, чтобы буферизовать 100 ГБ ZVOL, используемый "qemu-img". Или есть способ ограничить использование памяти для "qemu-img convert", чтобы он буферизовал ZVOL только до 1 ГБ, возможно?

Alwin

Guest

22.02.2018 14:41:00

В репозитории pvetest есть новый пакет ZFS, пожалуйста, протестируйте его. Также есть более новая версия ядра, стоит попробовать. Операция клонирования определенно является операцией с интенсивным вводом-выводом, насколько мне известно, единственный способ установить некоторые ограничения на неё - это использовать либо cstream, либо cgroup (ограничение памяти).

chrone

Guest

22.02.2018 14:45:00

Понял, попробую завтра и протестирую с другим блоком (lvm) или файловым хранилищем (qcow2), чтобы выяснить, будет ли qemu-img convert использовать всю доступную память для буфера 100 ГБ хранилища и вызовет ли это замедление из-за операций ввода-вывода в свопе.

chrone

Guest

26.02.2018 07:27:00

Сегодня протестировал последние пакеты из pvetest на хосте с 32 ГБ ОЗУ, и проблема все еще присутствует. Полное клонирование 100 ГБ шаблона из ZFS ZVOL в ZFS ZVOL вызывает такую ситуацию, что "qemu-img convert" использует всю доступную память в качестве буферизованных страниц, из-за чего система замедляется из-за нехватки памяти и значительного увеличения использования свопа. Отключение zfs_compressed_arc_enabled тоже не помогло. Я провел несколько тестов полного клонирования, и, казалось, qemu-img convert будет использовать всю доступную память как буферизованные страницы, если источник больше общего объема памяти и находится в формате изображения ZFS ZVOL. Полное клонирование шаблона 100 ГБ с qcow2 на ZFS в qcow2 на ZFS использует меньше 1% буферизованных страниц из 32 ГБ ОЗУ. Полное клонирование шаблона 100 ГБ с qcow2 на ZFS в ZFS ZVOL использует примерно 20% буферизованных страниц из 32 ГБ ОЗУ. Полное клонирование шаблона 100 ГБ с ZFS ZVOL в qcow2 на ZFS использует всю доступную память в качестве буферизованных страниц из 32 ГБ ОЗУ. Полное клонирование шаблона 100 ГБ с ZFS ZVOL в ZFS ZVOL использует всю доступную память в качестве буферизованных страниц из 32 ГБ ОЗУ. Я думаю, что есть проблема с qemu-img convert и ZFS ZVOL как форматом исходного изображения. Это какая-то утечка памяти или просто баг в qemu или zfs?

chrone

Guest

27.02.2018 05:44:00

Как указал @fabian, использование qemu-img convert -t none и -T none в качестве режима кэширования для исходного и целевого диска решило проблему. Код: /usr/bin/qemu-img convert -p -n -f raw -O raw -t none -T none /dev/zvol/rpool/data/vm-1081-disk-1 zeroinit:/dev/zvol/rpool/data/vm-1101-disk-2 Будет ли интерактивный вариант в интерфейсе онлайн-миграции диска и интерфейсе клонирования, чтобы можно было отметить -t none и -T none, если мы используем ZFS ZVOL в качестве формата исходного образа, или оба интерфейса автоматически определят, какой формат мы используем?

fabian Guest	#7 0 27.02.2018 10:41:00 Я думаю, мы можем просто принять обоснованное, автоматизированное решение, используя стандартные настройки типов хранилищ источника и назначения, а также форматы.

chrone Guest	#8 0 27.03.2018 17:10:00 Привет, Фабиан. Восстановление из резервной копии размером 200 ГБ с помощью vzdump как ZVOL тоже замедляет систему (веб-интерфейс Proxmox не реагирует). Это всё еще связано с проблемой qemu-img для ZVOL?

fabian

Guest

28.03.2018 10:43:00

это та же основная проблема (открытие zvol в Qemu с no-flush, что приводит к огромному количеству буферированной памяти на стороне ядра, что может вызвать коллапс ARC и, возможно, свопинг). исправление для qemu-img convert (офлайн перемещение диска/полное клонирование) уже есть в git, а исправление для vma extract/qmrestore все еще в разработке.

chrone Guest	#10 0 28.03.2018 10:56:00 Спасибо, Фабиан. С нетерпением жду этого.

deafsquad

Guest

#11

16.12.2019 19:21:00

эта проблема все еще существует в версии 6.1-3. Я клонировал 225G сырых блоков ZFS через GUI и получил задержку ввода-вывода до 25%. Я попробовал снова с помощью "qemu-img -t none -T none", как упоминалось выше, и задержка ввода-вывода достигла максимум 5%. acrsz был максимален на уровне 62G после этого, похоже, что при клонировании через GUI arc не использовался.

fabian Guest	#12 0 17.12.2019 10:06:00 офлайн в обоих случаях? онлайн "перемещение диска" — это совершенно другой код.

deafsquad Guest	#13 0 18.12.2019 12:18:00 Я тестировал онлайн, но похоже, что и там можно что-то улучшить. 25% задержка по io была довольно прерывистой, а 5% почему-то все еще были в порядке.

fabian

Guest

#14

19.12.2019 14:05:00

вы можете установить ограничение по пропускной способности для онлайн-клонирования (это еще не доступно в диалоговом окне клонирования, но вы можете установить его в datacenter.cfg для всех операций клонирования или вручную через API/qm clone для индивидуальных операций клонирования) — это должно облегчить проблему.

chrone Guest	#15 0 26.02.2018 11:24:00 Привет, @fabian! Хотел бы протестировать pve-ядро, о котором ты упоминал по адресу https://github.com/zfsonlinux/zfs/issues/7235. Спасибо.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры