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

freeze during and after blackup, Proxmox Виртуальная Среда

riri1310

Guest

28.10.2018 11:11:00

Привет, я использую встроенную функцию резервного копирования для бэкапа всех виртуальных машин в режиме снимков, потому что они все работают. Я заметил некоторые проблемы с подключением по SSH (у меня на виртуальной машине стоит monit, и он сообщил мне о проблеме с соединением SSH). Так что во время резервного копирования виртуальные машины иногда становятся недоступными, и странно, что после завершения резервного копирования proxmox зависает, и мне нужно сделать жесткую перезагрузку, чтобы всё снова запустить. Спасибо за помощь, если нужны какие-то команды из командной строки, не стесняйтесь спрашивать.

riri1310 Guest	#2 0 11.11.2018 11:52:00 Привет, мой vzdump уже использует "ionice priority: 7", стоит ли мне использовать планировщик ввода-вывода CFQ? Спасибо за помощь, мой сервер всегда зависает после этих резервных копий...

Humbug

Guest

11.11.2018 12:51:00

Я только что прочитал, что ionice обычно не работает с NFS: https://forum.proxmox.com/threads/about-of-ionice-in-vzdump.16485/#post-84955. Возможно, вы можете использовать другое место? Насколько мне известно, все остальные доступные планировщики ввода-вывода не учитывают параметры ionice, так что вам придется использовать CFQ с ним. Думаю, это все равно стоит попробовать. Может быть, вы можете немного подробнее рассказать о: - какой версии PVE использует ваш хост - сколько у вас гостей - какую ОС / версию используют ваши гости - сколько свободной оперативной памяти у вашего хоста - используете ли вы объединение страниц ядра (KSM).

riri1310

Guest

11.11.2018 12:57:00

Спасибо, вот некоторые детали: #pveversion -v Код: proxmox-ve: 5.2-2 (работающий ядро: 4.15.18-5-pve) pve-manager: 5.2-10 (работающая версия: 5.2-10/6f892b40) pve-kernel-4.15: 5.2-8 pve-kernel-4.15.18-5-pve: 4.15.18-24 corosync: 2.4.2-pve5 criu: 2.11.1-1~bpo90 glusterfs-client: 3.8.8-1 ksm-control-daemon: 1.2-2 libjs-extjs: 6.0.1-2 libpve-access-control: 5.0-8 libpve-apiclient-perl: 2.0-5 libpve-common-perl: 5.0-40 libpve-guest-common-perl: 2.0-18 libpve-http-server-perl: 2.0-11 libpve-storage-perl: 5.0-30 libqb0: 1.0.1-1 lvm2: 2.02.168-pve6 lxc-pve: 3.0.2+pve1-3 lxcfs: 3.0.2-2 novnc-pve: 1.0.0-2 proxmox-widget-toolkit: 1.0-20 pve-cluster: 5.0-30 pve-container: 2.0-29 pve-docs: 5.2-8 pve-firewall: 3.0-14 pve-firmware: 2.0-5 pve-ha-manager: 2.0-5 pve-i18n: 1.0-6 pve-libspice-server1: 0.12.8-3 pve-qemu-kvm: 2.11.2-1 pve-xtermjs: 1.0-5 qemu-server: 5.0-38 smartmontools: 6.5+svn4324-1 spiceterm: 3.0-5 vncterm: 1.5-3 zfsutils-linux: 0.7.11-pve1~bpo1 #cat /sys/block/sda/queue/scheduler Код: noop [deadline] cfq Хост добавил 4 контейнера, все работают на Debian 9 # free -m total used free shared buff/cache available Mem: 64110 24917 8502 306 30690 38174 Swap: 4095 402 3693 Думаю, я изменю [noop] на deadline (#cat /sys/block/sda/queue/scheduler), чтобы увидеть изменения и их последствия... Спасибо.

Humbug Guest	#5 0 11.11.2018 13:31:00 Похоже, у вас сейчас активен дедлайн (тот, что в скобках). Да, попробуйте.

riri1310 Guest	#6 0 11.11.2018 14:48:00 Ты прав, я сделал копию после изменения. Но плохая новость в том, что я только что провел тест, и система все равно зависает, даже с опцией дедлайна... У меня есть это в системном логе: Код: Nov 11 13:02:51 ns3091370 pvestatd[4659]: хранилище 'ftpbackup_ns3091370' не в сети Nov 11 13:02:52 ns3091370 pvestatd[4659]: время обновления статуса (6.146 секунд) Похоже, что резервный диск NFS имел какие-то проблемы с подключением к хосту (диск — резервная копия от OVH).

Читают тему

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