Привет, я обновил ядро до этой версии всего лишь вчера, а сегодня наш гипервизор выдал ядровую панику, и journald жаловался, что не может ничего записать. Виртуальные машины работали, но когда я пытался что-то записать на диск, система зависала. Спустя еще 10 минут виртуальные машины перестали отвечать. После перезагрузки все вернулось в норму. У меня нет больше информации, но я заметил, что в этой версии были некоторые патчи, касающиеся ZFS. Так что пока я откатываюсь на 4.15.18-7.
at24106
Guest
0
31.03.2019 09:46:00
Привет, у меня возникла серьезная проблема, после перезагрузки система не загружается, так как ZFS блокирует ядро (сообщение 120 секунд)... ZFS на Proxmox для меня мертв, слишком нестабилен для продакшна.
at24106
Guest
0
30.03.2019 09:35:00
Дорогой, это касается также и не JBOD. Есть проблема с ZFS на Proxmox, потому что такого не происходит вне Proxmox. Есть несколько тем с этой проблемой, когда высокая нагрузка на диск вызывает зависание ядра (сообщения каждые 120 секунд). Кажется, это проблема, вызванная ядром Proxmox (вероятно, таймер должен быть 1000 вместо 250) - альтернативное решение заключалось в том, чтобы создать отдельный пул ZFS для ОС и ВМ, это немного помогает, некоторые люди устанавливают лимиты ввода-вывода на ВМ, но это не помогает с бэкапами.
t.lamprecht
Guest
0
30.03.2019 10:50:00
Что? Откуда у тебя это? Ядро не должно влиять на это вообще... Какую версию ZFS и на какой дистрибутив с каким ядром ты тестировал (давно), где это не происходит? Может, мы сможем посмотреть, какие различия могут это решить. Да, но "задача зависла на 120 секунд" — это общая ошибка и может быть вызвана множеством причин... Мы и разработчики ZFS уже исправили много таких причин, по которым это происходило, и довольно много обсуждений уже не актуальны.
at24106
Guest
0
30.03.2019 11:33:00
Это случилось и на Archlinux, и решение состоит в том, чтобы увеличить таймер до 1000. Меня беспокоит то, что конфигурация Proxmox составляет 250, но когда вы это измеряете, вы получаете 100, и я не знаю, почему так. Самый простой способ — сделать ядро с 1000 и попробовать снова. У меня эта проблема на всех моих установках ZFS в proxmox — просто сделайте dd для образа vm, и после нескольких десятков гигабайт он останавливается. Есть отчеты о ZFS с версии x.7 до x.15 с этой проблемой. В основном это связано с тем, что zfs не возвращает планировщику управление дисковым вводу-выводом обратно к ядру, из-за чего процесс зависает. Я провел отладку с запланированной задачей, которая устанавливает sys для разморозки zfs, и так вы получаете контроль обратно при зависании, но только на короткий срок. 120 секунд полностью зависит от zfs. Я видел, как это полностью блокирует дисковый ввод-вывод, и поэтому могут работать только программы, которые находятся в памяти. Есть отчеты о том, что когда вы создаете два zfs, один для root и один для vm, то vm больше не может блокировать его (как сейчас), но если вы выполняете резервные копии и получаете доступ к root, это все равно происходит.
t.lamprecht
Guest
0
30.03.2019 14:11:00
Есть ссылки или источники на эту тему? Я ничего не нашёл, а ядро Archlinux настроено на работу с частотой 300 Гц. И да, мы используем 250 Гц в сочетании с "CONFIG_NO_HZ_IDLE" (отключаем тики на бездействующих ядрах CPU), что является хорошим компромиссом между точностью таймера и количеством пробуждений в секунду (которые дорогостоящие как с точки зрения производительности, так и энергопотребления, хотя первое действительно важно для PVE, а второе больше касается мобильных устройств). Сейчас мы используем динамические тики, так что у вас уже есть всё между 100 и 1500 в зависимости от потребностей, см. . Это похоже на баг в ZFS, который можно сообщить разработчикам ZFS на Linux, подобные вещи — это общая проблема, и увеличение количества таймеров не решит её, это может снизить вероятность, но не является решением таких багов. Это может быть связано с ZFS (никогда не утверждайте, что это не может быть связано с ZFS), и действительно в вашем случае и некоторых других это так, но это также может быть вызвано ошибками в определённых сетевых картах или их драйверах/прошивке (что вы также найдёте в отчётах здесь) или чем-то другим, что может блокировать более чем на 120 секунд, например, ИО на мёртвой NFS-монтировке. Также проблема в ZFS может возникнуть по различным причинам (это я и пытался сказать в последнем ответе), некоторые из них уже решены... В этом и проблема, я не могу воспроизвести это: Код: # zfs create -V $[128 * 1<<30] toms-big-pool/foo # создаёт vdev с размером около 130 ГБ # dd if=/dev/urandom of=/dev/toms-big-pool/foo bs=1M count=$[1<<16] # записываем случайные данные (из urandom, без блокировок), ~ 64 ГБ 65536+0 записей в 65536+0 записей из 68719476736 байт (69 ГБ, 64 ГиБ) скопировано, 543.355 с, 252 МБ/с или вы делаете что-то другое? Чёткие шаги с вашей стороны, чтобы мы могли убедиться, что разницы нет, были бы лучшими для воспроизведения этого… Какое у вас оборудование (чем больше деталей, тем лучше: диски, ОЗУ, ЦП, производитель, есть ли аппаратный RAID и т.д.)?
at24106
Guest
0
30.03.2019 14:36:00
Привет, вот как воспроизвести это: стандартная установка Proxmox ZFS root на сервере с ISO (Hetzner EX42, 64 ГБ ОЗУ, 4 ядра) a) 4TB b) 4TB Enterprise SATA с ZFS RAID Z+1 После установки добавь 100 ГБ раздел для чтения и 100 ГБ SSD кэша журналов, но это происходит и без этого шага. Без дедупликации, без сжатия Создай виртуальную машину с диском ZFS объемом 1,5 ТБ с virtio Загрузите ВМ с любой Linux-спасательной системы (например, Sysrescuecd) и передай с удаленного KVM сервера раздел (здесь размер 1,5 ТБ) на локальный диск (который является образом диска ZFS) ssh root@remoteserver.com "dd if=/dev/vg1/partiton bs=4M | gzip -1 -" | gunzip -1 - | pv -s 1500G | dd of=/dev/sda bs=4m Начинается со 60 МБ/с... спустя 10-20 минут скорость падает до 200 КБ/с - 2 МБ/с, а позже полностью зависает без загрузки ЦП.
at24106
Guest
0
30.03.2019 15:04:00
Похоже, что есть смягчение... когда virtio не активирован, скорость диска падает примерно на 60%, и тогда не происходит этой зависания.
at24106
Guest
0
31.03.2019 08:12:00
Привет, смягчение без virtio применимо только для низкой нагрузки, как указано выше. Если нагрузка увеличивается, система все равно зависает с SATA. Посмотри пример без gzip ssh root@remoteserver.com "dd if=/dev/vg1/partiton bs=4M | pv -s 1500G | dd of=/dev/sda bs=4M
t.lamprecht
Guest
0
31.03.2019 11:16:00
Что, ты действительно делаешь RAIDZ1 всего с двумя дисками? Это не имеет смысла, и наш установщик даже не разрешает это... С двумя дисками поддерживается только зеркалирование (RAID1), и это имеет смысл, если кто-то хочет получить производственную систему, а не систему, ожидающую аварии. Так как ты вообще установил Proxmox VE для такой конфигурации? Можешь выложить вывод следующего: Код: pve# zpool status pve# pveversion -v virtio что, SCSI на VirtIO-SCSI или VirtIO Block? Потому что я бы настаивал на SCSI на шине virtio-scsi, так как VirtioBlk не только лишен некоторых возможностей, он старее и давно не развивался. Твои воспроизведения довольно сложные, можешь упростить это до чего-то, что касается только хоста, полностью исключив ВМ из факторов? Код: pve# zfs create -V 1.5T POOLNAME/freeze-test pve# dd if=/dev/urandom status=progress of=/dev/POOLNAME/freeze-test bs=1M count=1G (К твоему сведению: опция status=progress в новейшем dd позволяет обходиться без таких вещей, как "pv", она напрямую сообщает, сколько и с какой скоростью записано) Если у тебя действительно настроен RaidZ1, я бы настоятельно рекомендовал попробовать снова с конфигурацией RAID1 или добавить третий диск, чтобы RAIDZ1 стал иметь смысл. Мы сами, и тысячи наших пользователей успешно используют ZFS на PVE в производстве, конечно, есть проблемы (как с любой технологией хранения в некоторых конфигурациях), но давай не будем обобщать несколько проблем.
at24106
Guest
0
31.03.2019 15:08:00
Дорогой, извини, это была не RAIDZ+1... на втором сервере был RAID1. Еще раз спасибо за помощь, очень признателен! Устанавливаю на базе Debian Stretch RAID1 и LVM, а сверху Proxmox из репозитория. Хочу узнать, будет ли это работать без ZFS на этом оборудовании.
t.lamprecht
Guest
0
31.03.2019 16:17:00
Хорошо, теперь всё снова имеет смысл, спасибо за пояснение. Хмм, хотя бы это: Код: pve# zfs create -V 1.5T toms-big-pool/freeze-test # запишите как минимум 1.5 TiB pve# dd if=/dev/urandom status=progress of=/dev/toms-big-pool/freeze-test bs=1M count=2M 1649213964288 байт (1.6 TB, 1.5 TiB) скопировано, 13731 с, 120 МБ/с dd: ошибка записи '/dev/toms-big-pool/freeze-test': Нет места на устройстве 1572865+0 записей в 1572864+0 записей out 1649267441664 байт (1.6 TB, 1.5 TiB) скопировано, 13752.4 с, 120 МБ/с без проблем прошел на 4TB HDD, скорость оставалась довольно стабильной. Если получится, было бы здорово выполнить ту же проверку, что и я (см. выше код), чтобы посмотреть, можем ли мы произвести это только через хост, без ВМ между ними.
at24106
Guest
0
21.04.2019 07:42:00
Дорогие, эта команда вызывает такое же зависание на хосте. Тем временем я перешел на LVM/LVM thin с SSD-кэшем на том же оборудовании, и все работает прекрасно уже 3 недели (никаких проблем). Оборудование следующее — возможно, у другого человека с такой же проблемой стоят такие же компоненты. Это корневой сервер от Hetzner.de: (пожалуйста, не расценивайте это как рекламу) Intel® Core™ i7-6700 Quad-Core 64 GB DDR4 RAM 2 x 4 TB SATA Enterprise Hard Drive 7200 rpm 00:00.0 Шинный мост: Intel Corporation Device 591f (rev 05) 00:02.0 VGA совместимый контроллер: Intel Corporation Device 5912 (rev 04) 00:14.0 USB контроллер: Intel Corporation Sunrise Point-H USB 3.0 xHCI Controller (rev 31) 00:14.2 Контроллер обработки сигналов: Intel Corporation Sunrise Point-H Thermal subsystem (rev 31) 00:16.0 Контроллер связи: Intel Corporation Sunrise Point-H CSME HECI #1 (rev 31) 00:17.0 SATA контроллер: Intel Corporation Sunrise Point-H SATA controller [AHCI mode] (rev 31) 00:1f.0 ISA мост: Intel Corporation Sunrise Point-H LPC Controller (rev 31) 00:1f.2 Контроллер памяти: Intel Corporation Sunrise Point-H PMC (rev 31) 00:1f.4 SMBus: Intel Corporation Sunrise Point-H SMBus (rev 31) 00:1f.6 Ethernet контроллер: Intel Corporation Ethernet Connection (2) I219-LM (rev 31) DMI: FUJITSU /D3401-H2, BIOS V5.0.0.12 R1.19.0.SR.1 для D3401-H2x 08/24/2018 dmesg в приложенном файле.
zeuxprox
Guest
0
19.03.2020 15:32:00
Привет, я сейчас прочитал этот пост и, как я написал в этом сообщении , у меня та же самая проблема (последний раз это было два дня назад), и я не знаю, что больше делать. Я обновил биос, Proxmox (с pve-подпиской) и всё до последней версии 5.4: pveversion -v: Код: proxmox-ve: 5.4-2 (используемое ядро: 4.15.18-26-pve) pve-manager: 5.4-13 (используемая версия: 5.4-13/aee6f0ec) pve-kernel-4.15: 5.4-14 pve-kernel-4.15.18-26-pve: 4.15.18-54 pve-kernel-4.15.18-24-pve: 4.15.18-52 pve-kernel-4.15.18-21-pve: 4.15.18-48 pve-kernel-4.15.18-16-pve: 4.15.18-41 pve-kernel-4.15.18-11-pve: 4.15.18-34 pve-kernel-4.15.18-9-pve: 4.15.18-30 pve-kernel-4.15.18-8-pve: 4.15.18-28 pve-kernel-4.15.18-7-pve: 4.15.18-27 pve-kernel-4.15.17-1-pve: 4.15.17-9 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-12 libpve-apiclient-perl: 2.0-5 libpve-common-perl: 5.0-56 libpve-guest-common-perl: 2.0-20 libpve-http-server-perl: 2.0-14 libpve-storage-perl: 5.0-44 libqb0: 1.0.3-1~bpo9 lvm2: 2.02.168-pve6 lxc-pve: 3.1.0-7 lxcfs: 3.0.3-pve1 novnc-pve: 1.0.0-3 openvswitch-switch: 2.7.0-3 proxmox-widget-toolkit: 1.0-28 pve-cluster: 5.0-38 pve-container: 2.0-41 pve-docs: 5.4-2 pve-edk2-firmware: 1.20190312-1 pve-firewall: 3.0-22 pve-firmware: 2.0-7 pve-ha-manager: 2.0-9 pve-i18n: 1.1-4 pve-libspice-server1: 0.14.1-2 pve-qemu-kvm: 3.0.1-4 pve-xtermjs: 3.12.0-1 qemu-server: 5.0-55 smartmontools: 6.5+svn4324-1 spiceterm: 3.0-5 vncterm: 1.5-3 zfsutils-linux: 0.7.13-pve1~bpo2 статус zpool: Код: pool: HDD-Pool state: ONLINE scan: scrub repaired 0B in 22h26m with 0 errors on Sun Mar 8 22:50:54 2020 config: NAME STATE READ WRITE CKSUM HDD-Pool ONLINE 0 0 0 raidz2-0 ONLINE 0 0 0 scsi-35000cca26ac15b54 ONLINE 0 0 0 scsi-35000cca26ad40cbc ONLINE 0 0 0 scsi-35000cca26ac4cfdc ONLINE 0 0 0 scsi-35000cca26abed87c ONLINE 0 0 0 scsi-35000cca26ad81e74 ONLINE 0 0 0 scsi-35000cca26ace9470 ONLINE 0 0 0 logs nvme-eui.334842304b3049160025384100000004-part1 ONLINE 0 0 0 cache nvme-eui.334842304b3049160025384100000004-part3 ONLINE 0 0 0 errors: No known data errors pool: SSD-Pool state: ONLINE scan: scrub repaired 0B in 0h34m with 0 errors on Sun Mar 8 00:58:36 2020 config: NAME STATE READ WRITE CKSUM SSD-Pool ONLINE 0 0 0 raidz2-0 ONLINE 0 0 0 ata-SAMSUNG_MZ7KM480HMHQ-00005_S3F4NX0K604708 ONLINE 0 0 0 ata-SAMSUNG_MZ7KM480HMHQ-00005_S3F4NX0K604709 ONLINE 0 0 0 ata-SAMSUNG_MZ7KM480HMHQ-00005_S3F4NX0K604707 ONLINE 0 0 0 ata-SAMSUNG_MZ7KM480HMHQ-00005_S3F4NX0K604677 ONLINE 0 0 0 ata-SAMSUNG_MZ7KM480HMHQ-00005_S3F4NX0K604706 ONLINE 0 0 0 ata-SAMSUNG_MZ7KM480HMHQ-00005_S3F4NX0K604672 ONLINE 0 0 0 errors: No known data errors pool: rpool state: ONLINE scan: scrub repaired 0B in 0h0m with 0 errors on Sun Mar 8 00:24:18 2020 config: NAME STATE READ WRITE CKSUM rpool ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 sdm2 ONLINE 0 0 0 sdn2 ONLINE 0 0 0 errors: No known data errors Продолжай...
