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

проблема ввода/вывода, Proxmox Виртуальная Среда

udi

Guest

12.12.2011 01:46:00

Привет, сегодняшняя задача резервного копирования не хочет заканчиваться. Задержка ввода-вывода на ноде около 50%, иконки ВМ чёрные, хотя они работают. Вот системный лог:

Code:
Dec 11 23:28:09 genya vzdump[279919]: INFO: Starting Backup of VM 109 (qemu)
Dec 11 23:28:09 genya qm[282317]: <root@pam> update VM 109: -lock backup
Dec 11 23:28:11 genya qm[282331]: <root@pam> starting task UPID:genya:00044EDC:010C0F34:4EE52E7B:qmsuspend:109:root@pam:
Dec 11 23:28:11 genya qm[282332]: suspend VM 109: UPID:genya:00044EDC:010C0F34:4EE52E7B:qmsuspend:109:root@pam:
Dec 11 23:28:11 genya qm[282331]: <root@pam> end task UPID:genya:00044EDC:010C0F34:4EE52E7B:qmsuspend:109:root@pam: OK
Dec 11 23:28:12 genya qm[282391]: <root@pam> starting task UPID:genya:00044F18:010C0F95:4EE52E7C:qmresume:109:root@pam:
Dec 11 23:28:12 genya qm[282392]: resume VM 109: UPID:genya:00044F18:010C0F95:4EE52E7C:qmresume:109:root@pam:
Dec 11 23:28:12 genya qm[282391]: <root@pam> end task UPID:genya:00044F18:010C0F95:4EE52E7C:qmresume:109:root@pam: OK
Dec 11 23:28:25 genya pvestatd[2146]: статус обновления (5.661 секунд)
Dec 11 23:28:35 genya pvestatd[2146]: статус обновления (6.015 секунд)
Dec 11 23:32:17 genya pvestatd[2146]: статус обновления (7.153 секунд)
Dec 11 23:32:25 genya pvestatd[2146]: статус обновления (6.422 секунд)
Dec 11 23:32:35 genya pvestatd[2146]: статус обновления (5.765 секунд)
Dec 11 23:32:45 genya pvestatd[2146]: статус обновления (5.923 секунд)
Dec 11 23:32:54 genya pvestatd[2146]: статус обновления (5.521 секунд)
Dec 11 23:34:35 genya pvestatd[2146]: статус обновления (5.484 секунд)
Dec 11 23:34:45 genya pvestatd[2146]: статус обновления (6.319 секунд)
Dec 11 23:34:58 genya pvestatd[2146]: статус обновления (9.222 секунд)
Dec 11 23:35:04 genya pvestatd[2146]: статус обновления (5.222 секунд)
Dec 11 23:35:14 genya pvestatd[2146]: статус обновления (5.201 секунд)
Dec 11 23:35:25 genya pvestatd[2146]: статус обновления (5.814 секунд)
Dec 11 23:35:36 genya pvestatd[2146]: статус обновления (7.018 секунд)
Dec 11 23:37:25 genya pvedaemon[280295]: <root@pam> успешная авторизация пользователя 'root@pam'
Dec 11 23:38:16 genya kernel: INFO: задача lvremove:283008 заблокирована более 120 секунд.
Dec 11 23:38:16 genya kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" отключит это сообщение.
Dec 11 23:38:16 genya kernel: lvremove D ffff8802bb8fd3e0 0 283008 279919 0 0x00000000
Dec 11 23:38:16 genya kernel: ffff8804488a3b78 0000000000000086 0000000000000000 ffff8805294cd500
Dec 11 23:38:16 genya kernel: ffff8804488a3b48 ffffffff813f473c 0000000000000008 000000010a7aef82
Dec 11 23:38:16 genya kernel: ffff8802bb8fd9a8 ffff8804488a3fd8 000000000000f788 ffff8802bb8fd9a8
Dec 11 23:38:16 genya kernel: Call Trace:
Dec 11 23:38:16 genya kernel: [<ffffffff813f473c>] ? dm_table_unplug_all+0x5c/0xd0
Dec 11 23:38:16 genya kernel: [<ffffffff814e7a93>] io_schedule+0xa3/0x110
Dec 11 23:38:16 genya kernel: [<ffffffff811c328e>] __blockdev_direct_IO+0x6fe/0xc20
Dec 11 23:38:16 genya kernel: [<ffffffff81242dcd>] ? get_disk+0x7d/0xf0
Dec 11 23:38:16 genya kernel: [<ffffffff811c0e97>] blkdev_direct_IO+0x57/0x60
Dec 11 23:38:16 genya kernel: [<ffffffff811c0060>] ? blkdev_get_blocks+0x0/0xc0
Dec 11 23:38:16 genya kernel: [<ffffffff8111f3ab>] generic_file_aio_read+0x70b/0x780
Dec 11 23:38:16 genya kernel: [<ffffffff811c1971>] ? blkdev_open+0x71/0xc0
Dec 11 23:38:16 genya kernel: [<ffffffff81184753>] ? __dentry_open+0x113/0x330
Dec 11 23:38:16 genya kernel: [<ffffffff8121ece8>] ? devcgroup_inode_permission+0x48/0x50
Dec 11 23:38:16 genya kernel: [<ffffffff811870da>] do_sync_read+0xfa/0x140
Dec 11 23:38:16 genya kernel: [<ffffffff81198252>] ? user_path_at+0x62/0xa0
Dec 11 23:38:16 genya kernel: [<ffffffff810922d0>] ? autoremove_wake_function+0x0/0x40
Dec 11 23:38:16 genya kernel: [<ffffffff811c042c>] ? block_ioctl+0x3c/0x40
Dec 11 23:38:16 genya kernel: [<ffffffff8119a862>] ? vfs_ioctl+0x22/0xa0
Dec 11 23:38:16 genya kernel: [<ffffffff8119aa0a>] ? do_vfs_ioctl+0x8a/0x5d0
Dec 11 23:38:16 genya kernel: [<ffffffff81187ae5>] vfs_read+0xb5/0x1a0
Dec 11 23:38:16 genya kernel: [<ffffffff81187c21>] sys_read+0x51/0x90
Dec 11 23:38:16 genya kernel: [<ffffffff8100b242>] system_call_fastpath+0x16/0x1b
Dec 11 23:38:16 genya kernel: INFO: задача vgs:283018 заблокирована более 120 секунд.
Dec 11 23:38:16 genya kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" отключит это сообщение.
Dec 11 23:38:16 genya kernel: vgs D ffff8805390a0ee0 0 283018 2146 0 0x00000000
Dec 11 23:38:16 genya kernel: ffff88033f04bb78 0000000000000082 ffff88036c7c1f80 ffff8805294cd500
Dec 11 23:38:16 genya kernel: ffff88033f04bb48 ffffffff813f473c 0000000000000008 0000000000001000
Dec 11 23:38:16 genya kernel: ffff8805390a14a8 ffff88033f04bfd8 000000000000f788 ffff8805390a14a8
Dec 11 23:38:16 genya kernel: Call Trace:
Dec 11 23:38:16 genya kernel: [<ffffffff813f473c>] ? dm_table_unplug_all+0x5c/0xd0
Dec 11 23:38:16 genya kernel: [<ffffffff8109cc89>] ? ktime_get_ts+0xa9/0xe0
Dec 11 23:38:16 genya kernel: [<ffffffff814e7a93>] io_schedule+0xa3/0x110
Dec 11 23:38:16 genya kernel: [<ffffffff811c328e>] __blockdev_direct_IO+0x6fe/0xc20
Dec 11 23:38:16 genya kernel: [<ffffffff81242dcd>] ? get_disk+0x7d/0xf0
Dec 11 23:38:16 genya kernel: [<ffffffff811c0e97>] blkdev_direct_IO+0x57/0x60
Dec 11 23:38:16 genya kernel: [<ffffffff811c0060>] ? blkdev_get_blocks+0x0/0xc0
Dec 11 23:38:16 genya kernel: [<ffffffff8111f3ab>] generic_file_aio_read+0x70b/0x780
Dec 11 23:38:16 genya kernel: [<ffffffff811c1971>] ? blkdev_open+0x71/0xc0
Dec 11 23:38:16 genya kernel: [<ffffffff81184753>] ? __dentry_open+0x113/0x330
Dec 11 23:38:16 genya kernel: [<ffffffff8121ece8>] ? devcgroup_inode_permission+0x48/0x50
Dec 11 23:38:16 genya kernel: [<ffffffff811870da>] do_sync_read+0xfa/0x140
Dec 11 23:38:16 genya kernel: [<ffffffff81198252>] ? user_path_at+0x62/0xa0
Dec 11 23:38:16 genya kernel: [<ffffffff810922d0>] ? autoremove_wake_function+0x0/0x40
Dec 11 23:38:16 genya kernel: [<ffffffff811c042c>] ? block_ioctl+0x3c/0x40
Dec 11 23:38:16 genya kernel: [<ffffffff8119a862>] ? vfs_ioctl+0x22/0xa0
Dec 11 23:38:16 genya kernel: [<ffffffff8119aa0a>] ? do_vfs_ioctl+0x8a/0x5d0
Dec 11 23:38:16 genya kernel: [<ffffffff81187ae5>] vfs_read+0xb5/0x1a0
Dec 11 23:38:16 genya kernel: [<ffffffff81187c21>] sys_read+0x51/0x90
Dec 11 23:38:16 genya kernel: [<ffffffff8100b242>] system_call_fastpath+0x16/0x1b

Что делать? Перезагружать пока не стал.

bazzi Guest	#2 0 28.12.2011 09:51:00 Те же самые проблемы у нас. Это происходит на разных системах, и сжатие было включено. Кластер работает на IMS и делает резервное копирование через NFS-шару на Synology DS810+.

dietmar Guest	#3 0 30.12.2011 09:29:00 Я тоже заметил эту ошибку здесь, но пока не могу её воспроизвести.

bazzi Guest	#4 0 30.12.2011 09:32:00 Мы полностью отключили резервное копирование на данный момент, так что кластер будет работать как обычно. Странно то, что это происходит на разных узлах каждый раз...

e100

Guest

02.01.2012 01:40:00

Похоже, проблема связана с lvm. И bread-baker, и udi говорят, что lvremove зависает. Поиск в Гугле по теме зависания lvremove привёл меня сюда: https://www.multifake.net/2011/12/debian-squeeze-lvm-udev-etc-buggy/. Интересно, что этот парень использует Squeeze с Xen и сталкивается с похожими проблемами. Если у вас получится воспроизвести проблему, не могли бы вы запустить другие команды lvm, например lvs, lvdisplay, lvscan, пока резервное копирование зависает?

ПРИМЕЧАНИЕ: нашёл этот баг: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618016, который ссылается на: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549691, там возможно есть решение.

bread-baker Guest	#6 0 02.01.2012 02:08:00 Если проблему можно воспроизвести, можешь попробовать запустить другие команды lvm вроде lvs, lvdisplay, lvscan в тот момент, когда резервное копирование зависает? Насколько я помню, никакие команды lvm не работали, и единственным способом вернуть систему в рабочее состояние был аппаратный сброс питания. После прочтения https://www.multifake.net/2011/12/debian-squeeze-lvm-udev-etc-buggy/ мне кажется, что проблема может быть связана с подключённым USB-накопителем... У меня часто подключён 500 ГБ диск, отформатированный в ext3, к тестовым серверам proxmox 2.0. [мы используем его для переноса дампов pve вне офиса].

Читают тему

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