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

Медленные снимки?, Proxmox Виртуальная Среда

MoreDakka

Guest

29.11.2022 22:33:00

Привет. У нас есть кластер Proxmox/Ceph из 4 узлов (Ceph на 40g сетях, соединения Prox на 10g сетях, интернет через два 1g сетевых интерфейса), Ceph использует 8x2TB SM863a дисков. Проблема в снимках, я их не использую часто, но хотел протестировать перед тем, как запустить клиентов: Эта часть быстрая: /dev/rbd4 сохраняет состояние ВМ и ОЗУ с использованием хранилища 'Ceph-RBDStor' 1.51 MiB за 0с 836.81 MiB за 1с 1.69 GiB за 2с 2.57 GiB за 3с 3.49 GiB за 4с 4.33 GiB за 5с 5.13 GiB за 6с 5.93 GiB за 7с 6.88 GiB за 8с 7.83 GiB за 9с 8.76 GiB за 10с 9.67 GiB за 11с 10.59 GiB за 12с 11.50 GiB за 13с 12.37 GiB за 14с 13.23 GiB за 15с ==== Теперь это лежит тут уже 8м 59с (только что завершилось), вот остальная часть лога: завершено сохранение состояния ВМ за 18с, сохранено 13.97 GiB снимок 'drive-scsi0' (Ceph-RBDStor:vm-101-disk-1) Создание снимка: 10% завершено... Создание снимка: 100% завершено... готово. снимок 'drive-efidisk0' (Ceph-RBDStor:vm-101-disk-0) Создание снимка: 10% завершено... Создание снимка: 100% завершено... готово. снимок 'drive-tpmstate0' (Ceph-RBDStor:vm-101-disk-2) Создание снимка: 10% завершено... Создание снимка: 100% завершено... готово. ЗАДАЧА УСПЕШНО ЗАВЕРШЕНА ==== Что вызывает такую длительность? root@pve1-cpu1:~# pveversion -v proxmox-ve: 7.3-1 (работает ядро: 5.15.74-1-pve) pve-manager: 7.3-3 (работает версия: 7.3-3/c3928077) pve-kernel-5.15: 7.2-14 pve-kernel-helper: 7.2-14 pve-kernel-5.13: 7.1-9 pve-kernel-5.11: 7.0-10 pve-kernel-5.15.74-1-pve: 5.15.74-1 pve-kernel-5.15.64-1-pve: 5.15.64-1 pve-kernel-5.15.60-2-pve: 5.15.60-2 pve-kernel-5.15.60-1-pve: 5.15.60-1 pve-kernel-5.15.53-1-pve: 5.15.53-1 pve-kernel-5.15.39-4-pve: 5.15.39-4 pve-kernel-5.15.39-3-pve: 5.15.39-3 pve-kernel-5.15.39-1-pve: 5.15.39-1 pve-kernel-5.15.35-3-pve: 5.15.35-6 pve-kernel-5.15.35-2-pve: 5.15.35-5 pve-kernel-5.15.35-1-pve: 5.15.35-3 pve-kernel-5.13.19-6-pve: 5.13.19-15 pve-kernel-5.13.19-4-pve: 5.13.19-9 pve-kernel-5.13.19-2-pve: 5.13.19-4 pve-kernel-5.13.19-1-pve: 5.13.19-3 pve-kernel-5.11.22-7-pve: 5.11.22-12 pve-kernel-5.11.22-5-pve: 5.11.22-10 pve-kernel-5.11.22-4-pve: 5.11.22-9 ceph: 16.2.9-pve1 ceph-fuse: 16.2.9-pve1 corosync: 3.1.7-pve1 criu: 3.15-1+pve-1 glusterfs-client: 9.2-1 ifupdown2: 3.1.0-1+pmx3 ksm-control-daemon: 1.4-1 libjs-extjs: 7.0.0-1 libknet1: 1.24-pve2 libproxmox-acme-perl: 1.4.2 libproxmox-backup-qemu0: 1.3.1-1 libpve-access-control: 7.2-5 libpve-apiclient-perl: 3.2-1 libpve-common-perl: 7.2-8 libpve-guest-common-perl: 4.2-3 libpve-http-server-perl: 4.1-5 libpve-storage-perl: 7.2-12 libspice-server1: 0.14.3-2.1 lvm2: 2.03.11-2.1 lxc-pve: 5.0.0-3 lxcfs: 4.0.12-pve1 novnc-pve: 1.3.0-3 proxmox-backup-client: 2.2.7-1 proxmox-backup-file-restore: 2.2.7-1 proxmox-mini-journalreader: 1.3-1 proxmox-offline-mirror-helper: 0.5.0-1 proxmox-widget-toolkit: 3.5.3 pve-cluster: 7.3-1 pve-container: 4.4-2 pve-docs: 7.3-1 pve-edk2-firmware: 3.20220526-1 pve-firewall: 4.2-7 pve-firmware: 3.5-6 pve-ha-manager: 3.5.1 pve-i18n: 2.8-1 pve-qemu-kvm: 7.1.0-4 pve-xtermjs: 4.16.0-1 qemu-server: 7.3-1 smartmontools: 7.2-pve3 spiceterm: 3.2-2 swtpm: 0.8.0~bpo11+2 vncterm: 1.7-1 zfsutils-linux: 2.1.6-pve1 root@pve1-cpu1:~#

fiona

Guest

27.03.2023 09:32:00

Хотя это должно повлиять на часть снимка, связанную с диском, я был бы удивлён, если бы это как-то значительно сказалось на части, связанной с ОЗУ (а именно об этом и идёт речь в этой теме). Что ж, часть ОЗУ по умолчанию сохраняется на том же носителе, что и диск, всегда в виде отдельного необработанного файла/объёма, но, кроме этого, она не должна зависеть от того, является ли диск qcow2 или находится в LVM-thin.

DC-CA1 Guest	#3 0 27.03.2023 12:58:00 Я только что обновился и подтверждаю, что проблема исчезла. Спасибо.

toomanylogins

Guest

27.03.2023 09:28:00

У меня была такая проблема. Снимки, особенно для Windows VM, значительно быстрее, если переключить хранилище с qcow2 на lvm thin. Восстановление снимка, даже после незначительных изменений, занимало 10 минут, а теперь всего секунды.

DC-CA1

Guest

26.03.2023 16:17:00

Привет, Фабиан. У нас проблема: делаем снимок для виртуальной машины с 2 дисками qcow2 (по 1TB и 2TB), всего 3TB, и 32GB ОЗУ. Виртуальная машина использует 10GB ОЗУ, но процесс приближается к 10GB, а на хосте с файловой системой GFS2 и 128GB ОЗУ (75% свободно) это занимает вечность. Пока я пишу это сообщение, я всегда завершал процесс через 20 минут — он движется от 1 до 11GB за 2-3 минуты, но останавливается и дальнейший прирост идет очень медленно. Снимок в состоянии, не использующем ОЗУ, завершает работу с 3TB хранилища за 1-2 минуты успешно. Текущие настройки: vm.dirty_background_ratio = 10, vm.min_free_kbytes = 524288, vm.swappiness = 1. Спасибо за помощь. Форматирую '/mnt/storage/images/200/vm-200-state-snap.raw', fmt=raw, size=69243764736, preallocation=off, сохраняю состояние ВМ и ОЗУ, используя хранилище 'storage 311.00 B в 0s, 60.31 MiB в 1s, 602.99 MiB в 2s, 835.72 MiB в 3s, 971.47 MiB в 4s, 1.32 GiB в 5s...' и так далее.

fiona Guest	#6 0 27.03.2023 08:45:00 Вы делаете резервные копии PBS на той же виртуальной машине? Проблема, когда снимки зависали после создания резервной копии PBS (хотя бы один раз), была исправлена в pve-qemu-kvm>=7.2.0-5. Если вы уже используете более новую версию, пожалуйста, поделитесь выводом команды pveversion -v.

Читают тему

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