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

kworker 99% IO, Proxmox Виртуальная Среда

Andrey Dudin

Guest

09.02.2019 01:45:00

Когда я мигрирую/восстанавливаю ВМ, я вижу, что kworker использует 99% ввода-вывода (по данным iotop). Другие ВМ на целевом узле иногда зависают. Все работающие ВМ на целевом узле показывают эту ошибку:

Я использую аппаратный RAID1. Lvm-thin пулы. Оборудование: R540 - Silver 4114 Raid: Perc H730 pveversion -v Код: # pveversion -v proxmox-ve: 5.3-1 (работающая версия ядра: 4.15.18-10-pve) pve-manager: 5.3-9 (работающая версия: 5.3-9/ba817b29) pve-kernel-4.15: 5.3-1 pve-kernel-4.15.18-10-pve: 4.15.18-32 corosync: 2.4.4-pve1 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.1-3 libpve-apiclient-perl: 2.0-5 libpve-common-perl: 5.0-45 libpve-guest-common-perl: 2.0-20 libpve-http-server-perl: 2.0-11 libpve-storage-perl: 5.0-37 libqb0: 1.0.3-1~bpo9 lvm2: 2.02.168-pve6 lxc-pve: 3.1.0-2 lxcfs: 3.0.2-2 novnc-pve: 1.0.0-2 proxmox-widget-toolkit: 1.0-22 pve-cluster: 5.0-33 pve-container: 2.0-34 pve-docs: 5.3-2 pve-edk2-firmware: 1.20181023-1 pve-firewall: 3.0-17 pve-firmware: 2.0-6 pve-ha-manager: 2.0-6 pve-i18n: 1.0-9 pve-libspice-server1: 0.14.1-2 pve-qemu-kvm: 2.12.1-1 pve-xtermjs: 3.10.1-1 qemu-server: 5.0-46 smartmontools: 6.5+svn4324-1 spiceterm: 3.0-5 vncterm: 1.5-3 zfsutils-linux: 0.7.12-pve1~bpo1 Я думаю, проблема может быть с dd. Потому что когда я использую живую миграцию с локальными дисками, я вижу копирование дисков с хорошей скоростью, и kworker спит. iotop: Код: Всего ЧТЕНИЕ ДИСКА: 21.26 K/s | Всего ЗАПИСЬ ДИСКА: 84.38 M/s Фактическое ЧТЕНИЕ ДИСКА: 21.26 K/s | Фактическая ЗАПИСЬ ДИСКА: 85.33 M/s TID ПРИОРИТЕТ ПОЛЬЗОВАТЕЛЬ ЧТЕНИЕ ДИСКА ЗАПИСЬ ДИСКА SWAPIN IO> КОМАНДА 4173 be/4 root 0.00 B 0.00 B 0.00 % 99.27 % [kworker/u80:2] 5091 be/4 root 89.00 K 0.00 B 0.00 % 87.92 % vgs --separator : --noheadings --units b ~-options vg_name,vg_size,vg_free,lv_count 2647 be/4 root 0.00 B 0.00 B 0.00 % 11.58 % [kworker/u82:0] 39193 be/4 root 4.00 K 0.00 B 0.00 % 4.34 % [kworker/u80:1] 4830 be/4 root 0.00 B 0.00 B 0.00 % 0.03 % [kworker/u81:1] 635 be/3 root 0.00 B 36.00 K 0.00 % 0.03 % [jbd2/dm-1-8] 4986 be/4 root 0.00 B 0.00 B 0.00 % 0.01 % [kworker/u81:4] 37696 be/4 root 0.00 B 0.00 B 0.00 % 0.01 % [kworker/u81:2] 4739 be/4 root 0.00 B 0.00 B 0.00 % 0.00 % [kworker/u82:3] 4352 be/4 root 0.00 B 929.50 M 0.00 % 0.00 % dd of=/dev/pve-hdd/vm-123-disk-2 conv=sparse отчет производительности: Код: + 14.02% 0.00% kworker/u80:2 [kernel.kallsyms] [k] ret_from_fork + 14.02% 0.00% kworker/u80:2 [kernel.kallsyms] [k] kthread + 14.02% 0.00% kworker/u80:2 [kernel.kallsyms] [k] worker_thread + 14.02% 0.00% kworker/u80:2 [kernel.kallsyms] [k] process_one_work + 14.02% 0.00% kworker/u80:2 [kernel.kallsyms] [k] do_worker + 14.02% 0.00% kworker/u80:2 [kernel.kallsyms] [k] process_prepared + 14.02% 0.01% kworker/u80:2 [kernel.kallsyms] [k] process_prepared_mapping + 13.60% 0.06% kworker/u80:2 [kernel.kallsyms] [k] inc_remap_and_issue_cell + 12.99% 0.02% kworker/u80:2 [kernel.kallsyms] [k] remap_and_issue + 12.93% 0.00% kworker/u80:2 [kernel.kallsyms] [k] issue + 12.86% 0.17% kworker/u80:2 [kernel.kallsyms] [k] generic_make_request Из dmesg хоста: Код: [Сб Фев 9 02:57:43 2019] ИНФО: задача dd:29806 заблокирована более чем на 120 секунд. [Сб Фев 9 02:57:43 2019] Загрязнено: P O 4.15.18-10-pve #1 [Сб Фев 9 02:57:43 2019] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" отключает это сообщение. [Сб Фев 9 02:57:43 2019] dd D 0 29806 29784 0x00000000 [Сб Фев 9 02:57:43 2019] трассировка вызовов: [Сб Фев 9 02:57:43 2019] __schedule+0x3e0/0x870 [Сб Фев 9 02:57:43 2019] schedule+0x36/0x80 [Сб Фев 9 02:57:43 2019] io_schedule+0x16/0x40 [Сб Фев 9 02:57:43 2019] wait_on_page_bit_common+0xf3/0x190 [Сб Фев 9 02:57:43 2019] ? page_cache_tree_insert+0xe0/0xe0 [Сб Фев 9 02:57:43 2019] __filemap_fdatawait_range+0xfa/0x160 [Сб Фев 9 02:57:43 2019] filemap_write_and_wait+0x4d/0x90 [Сб Фев 9 02:57:43 2019] __blkdev_put+0x7a/0x210 [Сб Фев 9 02:57:43 2019] ? fsnotify+0x259/0x440 [Сб Фев 9 02:57:43 2019] blkdev_put+0x4c/0xd0 [Сб Фев 9 02:57:43 2019] blkdev_close+0x34/0x70 [Сб Фев 9 02:57:43 2019] __fput+0xea/0x220 [Сб Фев 9 02:57:43 2019] ____fput+0xe/0x10 [Сб Фев 9 02:57:43 2019] task_work_run+0x9d/0xc0 [Сб Фев 9 02:57:43 2019] exit_to_usermode_loop+0xc4/0xd0 [Сб Фев 9 02:57:43 2019] do_syscall_64+0xf4/0x130 [Сб Фев 9 02:57:43 2019] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 [Сб Фев 9 02:57:43 2019] RIP: 0033:0x7f3fec42ccf0 [Сб Фев 9 02:57:43 2019] RSP: 002b:00007ffd46e71a08 EFLAGS: 00000246 ORIG_RAX: 0000000000000003 [Сб Фев 9 02:57:43 2019] RAX: 0000000000000000 RBX: 00007f3fec904698 RCX: 00007f3fec42ccf0 [Сб Фев 9 02:57:43 2019] RDX: 00007ffd46e71a70 RSI: 00007ffd46e71a70 RDI: 0000000000000001 [Сб Фев 9 02:57:43 2019] RBP: 0000000000000000 R08: 0000000000006000 R09: 0000000000004000 [Сб Фев 9 02:57:43 2019] R10: 00000000000005e1 R11: 0000000000000246 R12: ffffffffffffffff [Сб Фев 9 02:57:43 2019] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [Сб Фев 9 02:57:43 2019] ИНФО: задача systemd-udevd:33283 заблокирована более чем на 120 секунд. [Сб Фев 9 02:57:43 2019] Загрязнено: P O 4.15.18-10-pve #1 Мониторинг во время миграции:

sahostking Guest	#2 0 05.04.2020 14:28:00 Странно. Вы используете SATA-диски в RAID 1, и какая у них модель и производитель? Во-вторых, после внесения вышеуказанных изменений, видите ли вы в iotop ограничение пропускной способности на уровне 25 МБ/с?

brandon_welsch Guest	#3 0 05.04.2020 14:24:00 Я установить лимит скорости на 25 МБ/с, но проблема не решается. Миграция моей виртуальной машины объемом 20 ГБ никогда не заканчивается :'(.

brandon_welsch

Guest

05.04.2020 14:35:00

Для меня я использую 2x1 ТБ SSD (RAID 1). Модель Crucial_CT1050MX300SSD1. Результат iotop:

Логи Proxmox: Код: 2020-04-05 14:10:01 используйте выделенный сетевой адрес для отправки трафика миграции (...) 2020-04-05 14:10:01 начинается миграция ВМ 300 на узел 'dedicated' (...) 2020-04-05 14:10:01 найден локальный диск 'local-lvm:vm-300-disk-0' (в текущей конфигурации ВМ) 2020-04-05 14:10:01 копирую образы локальных дисков Логический том "vm-300-disk-0" создан.

brandon_welsch Guest	#5 0 05.04.2020 14:40:00 Я не понимаю, в чем дело. Я уже несколько часов пытаюсь найти причину, но так и не понял, почему это происходит.

sahostking

Guest

05.04.2020 14:56:00

Всё в порядке — я раньше использовал SSD Crucial, и они не могут быть причиной проблемы. Может быть, дело в пропускной способности вашей сети? Предполагаю, что выделенная сеть — 1Gbps или даже 10Gbps? Я проверил нашу конфигурацию, и в файле /etc/pve/datacenter.cfg у нас следующее: cat /etc/pve/datacenter.cfg keyboard: en-us # используйте выделенную сеть для миграции migration: secure,network=10.0.0.0/24 bwlimit: move=71680,restore=51200,default=51200,migration=51200,clone=51200 У нас нет проблем с использованием вышеописанного, и это стоит на довольно многих старых и новых серверах. Думаю, вам нужно найти узкое место где-то. Попробуйте понизить настройки ещё больше.

brandon_welsch

Guest

05.04.2020 15:09:00

Пропускная способность сети хорошая (1 Гбит/с выделенная сеть, да). Передача диска на целевой машине проходит довольно быстро. Но, кажется, она блокируется на целевой машине с процессом dd of=/dev/pve/vm-300-~k-0 conv=sparse bs=64k. Мне не кажется, что проблема в пропускной способности, скорее это вопрос ввода-вывода на диске, но я не вижу, где именно может быть проблема. У меня индикатор задержки ввода-вывода на интерфейсе Proxmox, который всегда показывает от 8 до 10 во время миграции. Скриншот из интерфейса Proxmox:

Для конфигурации /etc/pve/datacenter.cfg у меня следующее: Код: bwlimit: clone=25600,default=25600,migration=25600,move=25600,restore=25600
keyboard: fr
migration: secure

rnmkr

Guest

05.01.2021 00:06:00

Такие же проблемы, я восстанавливаю одну виртуальную машину из резервной копии. Это занимает целую вечность. Iotop показывает всего несколько Кб/с записи на диск, но при этом показывает 99,99% загрузки ввода-вывода, странно.

Aleksej Guest	#9 0 29.06.2021 22:26:00 Та же проблема. Спойлер: восстановление прогресса 93% (прочитано 31954567168 байт, продолжительность 53 сек) прогресс 94% (прочитано 32298172416 байт, продолжительность 53 сек) прогресс 95% (прочитано 32641777664 байт, продолжительность 54 сек) прогресс 96% (прочитано 32985382912 байт, продолжительность 55 сек) прогресс 97% (прочитано 33328988160 байт, продолжительность 56 сек) прогресс 98% (прочитано 33672593408 байт, продолжительность 56 сек) прогресс 99% (прочитано 34016198656 байт, продолжительность 56 сек) прогресс 100% (прочитано 34359738368 байт, продолжительность 56 сек) ----------------------------- всего прочитано байт 34359738368, sparse bytes 3074543616 (8.95%) уменьшение занимаемого пространства из-за 4K нулевых блоков 1.03% повторное сканирование томов... ---------------------------- и в завершение восстановление 32G ВМ - подчеркну, заняло около 3.5 часов... Я пробовал: ВМ на LVMthin --> ВМ на LVM thin, ВМ на ZFS, ВМ на qcow ВМ на qcow --> ВМ на LVM thin, ВМ на ZFS, ВМ на qcow С Proxmox 6.3 не было проблем добавлено: протестировал еще раз с разными вариантами на 6.3 - все в порядке. Так что могу сказать, что это ошибка Proxmox 6.4.

Читают тему

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