Первое: Я слышу ваши жалобы, но не стал бы так всё чернить. Мои первые шаги с ZFS много лет назад были очень похожи на ваши. Я также сталкивался с OOM (Out Of Memory) и крайней медлительностью. За почти два года на системах ZFS у меня не было ни одного OOM, и я использую их просто ради функционала, а не ради скорости по сравнению с "глупым блочным или файловым хранилищем". Вы написали, что у вас два диска и вы создали Raidz1? Зачем? Вы сравниваете несравнимое. Вам следовало создать зеркальный vdev в этой конфигурации. Больше информации здесь: https://constantin.glez.de/2010/01/23/home-server-raid-greed-and-why-mirroring-still-best/ Вы забываете, что ваша система ext4-qcow2 также будет использовать столько оперативной памяти, сколько сможет. Большинство людей не осознают этого, поскольку это поведение по умолчанию для каждой современной операционной системы. Для "реальных" бенчмарков всегда используют прямые I/O пути или очищают кеши, чтобы получить правильные показатели. Дело в том, что ZFS использует максимум 50% ОЗУ на Linux, а кэш страниц по умолчанию не имеет ограничений. С другой стороны, оба вида хранилищ страдают от малого объема кэша и будут медленными. Еще один важный аспект — это ваше оборудование. ZFS не является бюджетной потребительской файловой системой, как семья ext, это файловая система для оборудования класса "предприятие" и корпоративных решений. Два медленных диска, максимум с 7200 об/мин, не будут достаточно быстрыми — ни для чего. ZFS не будет хорошо работать на таких машинах, зачем ему это делать? Он не был для этого спроектирован. ZFS — это файловая система без ограничений... но на дальнем конце спектра. Вам стоит сравнить её в более широком контексте с большим количеством дисков и стандартным mdadm и ext4. У ext4 также есть много ограничений, которых нет у ZFS, таких как параллельный доступ и прочее. Мы тоже использовали mdadm... на протяжении десятилетий, без каких-либо проблем, но мы перешли почти на все системы, которые были достаточно большими, на ZFS. Да, он не так быстр, как мог бы быть, но это связано с теми функциями, которые нам действительно понравились: * прозрачная сжатие (это обеспечивает даже более высокую пропускную способность чтения/записи, чем ext4, в зависимости от ваших данных — даже на бюджетном оборудовании) * восстановление вместо глупого 1:1 копирования/паритета при пересоздании (или создание пула в 100 ТБ, который изначально уже высокодоступен) * в дополнение к сканированию / патрульным чтениям — прозрачное самовосстановление при каждом чтении. * поддержка обрезки (не по отношению к оборудованию, а к виртуальному диску) * 100% подтверждение валидности данных в зеркале из двух дисков. В глупом зеркале mdadm из двух дисков невозможно понять, какие данные верные, если блок не совпадает на обоих дисках. * снимки и возможность их передачи очень, очень эффективно (также репликация) Последний шаг был большой проблемой на mdadm с внешними резервными копиями. Мы снизили время внешнего резервного копирования через репликацию ZFS в почти 100 раз по сравнению с rsync, потому что можем передавать инкрементально и не обязаны копировать сами резервные копии на внешний диск, а только изменения. Это также требует гораздо меньшего объема памяти и, следовательно, позволяет сохранить более длинную историю или использовать меньшие диски. Этот факт полностью убедил нас выбрать ZFS, потому что вы просто не можете сделать это на системе, не основанной на CoW. Это также может помочь в вашем случае: vzdump В конфигурации ext4 вам нужно использовать vzdump, чтобы иметь что-то, что можно скопировать в другое место в качестве резервной копии. Да, вы можете сделать это и с ZFS, но делать это не следует, вам нужно сделать снимок вашей ВМ и передать гораздо меньшие дифференциальные данные на ваш резервный сайт. Это всегда будет быстрее, чем vzdump, потому что вам нужно лишь читать данные, присутствующие в самом новом снимке. Если у вас есть ZFS на вашем PVE (который, к сожалению, работает только на отдельных узлах и не в кластере с общим хранилищем), вы можете делать снимки и реплицировать с помощью встроенных инструментов, чтобы иметь резервную систему, имеющую, например, 15-кратную задержку. Полностью невозможно в конфигурации ext4 с mdadm. Итак, пару слов о производительности: медленнее ли он, чем ext4 на каком-то тестовом оборудовании? Да, конечно. Я использовал его на Raspberry PI 1-3, и он был почти мертвым медленным, но работал. Он определенно медленнее ext4 в системе с 2 или 4 дисками SATA на программном RAID. Но по нашему опыту (и я имею в виду всех сторонников ZFS здесь) он не в два раза медленнее, чем ext4 в различных сценариях использования.

Я использую Proxmox на потребительском оборудовании (жесткие диски, настольные материнские платы, память без ECC) всегда с ZFS, и для очень ограниченного количества ВМ скорость в целом приемлема. Лучшее улучшение, которое я только что начал внедрять, — это переход от жестких дисков к SSD. Обычно я использую два SSD начального уровня (серия Samsung EVO) в ZFS RAID-1 для установки Proxmox и виртуальных дисков, которым нужна большая скорость (ОС, базы данных, приложения), а затем добавляю 2 или более HDD (SATA 7200 об/мин) в RAID1 или RAID10 для хранения данных. У меня максимум 3 Windows ВМ на каждом сервере. У меня хорошие времена безотказной работы (некоторые серверы при меньших затратностях работают уже 2 года), и мне странно, что у вас OOM и перезагрузки, возможно, вы слишком сильно переобеспечиваете. Я стараюсь оставлять минимум 512МБ свободной оперативной памяти, в каждом сервере в /etc/sysctl.d у меня есть конфигурационный файл с кодом: vm.swappiness = 0 vm.min_free_kbytes = 524288

Попробуйте настроить vm.min_free_kbytes, чтобы всегда оставалась свободная память для Proxmox. Я это настраиваю на каждом сервере Proxmox, и, как я уже говорил, у меня нет проблем с зависаниями или перезагрузками. В ваших примерах, я думаю, что ваше максимальное значение ZFS ARC слишком велико, у Linux тоже есть свой кэш, и даже если он освобождается при необходимости, это занимает некоторое время. Если вашим виртуальным машинам нужно около половины оперативной памяти хоста (и если вы выделяете, например, 1 ГБ виртуальной машине, то эта машина использует не только 1 ГБ, а немного больше, можете проверить сами), я бы установил максимальный ZFS ARC в одну треть оперативной памяти, не больше, чтобы не создавать слишком высокую нагрузку на память. Старайтесь никогда не достигать 75% используемой оперативной памяти.

Привет, @Kurgan. Да, zfs в самом начале действительно сложен, и если не попробовать прочитать, переосмыслить и снова прочитать документацию, будет тяжело. Самое трудное — понять, как это чудовище работает. Но если ты готов потратить много часов, со временем твои zfs настройки начнут улучшаться. У zfs много настроек, которые можно сделать, даже на серверах с малым объемом памяти. Я использую zfs много лет на разных десктопах с 2 ГБ ОЗУ (в то время это не был proxmox) и с множеством сервисов. Но мне повезло, я столкнулся всего с парой перезагрузок. Теперь с Proxmox большинство моих узлов имеют 16 ГБ ОЗУ (базы данных, файловые серверы и многие другие, включая nfs, lizardfs и т.д.). Ни одной аварии или перезагрузки. Один трюк — использовать кэш zfs только для метаданных. Если ты используешь рекомендованный размер блока для своего создателя БД, можешь получить отличную производительность (с рядом других индивидуальных настроек zfs). Так что, если что-то не работает так, как ты надеялся, используя zfs, скорее всего, проблема кроется в твоих знаниях или неверном понимании твоей данных окружения (я повторяю эту мысль себе снова и снова, пока не удается решить свою проблему с zfs). Удачи!

Guletz и mbaldini, спасибо за ваши ответы. Я не эксперт по ZFS, использую его впервые в Proxmox, так как это его выбор по умолчанию для программного RAID. Раньше я всегда использовал md и ext4. Меня озадачивает тот факт, что у ZFS так много проблем в Proxmox, и, судя по тому, что я прочитал на этом форуме, ZFS очень плохо настроен в Proxmox. Вы (и многие другие) говорите мне настроить ZFS в Proxmox, чтобы он работал правильно, а я спрашиваю себя, почему эти настройки не являются настройками по умолчанию и почему об этом нет документации в Proxmox. Я пока выяснил следующее: я не должен использовать swap на ZFS (а Proxmox делает это по умолчанию, и это не настраивается в установщике). По крайней мере, область swap на ZFS должна иметь primarycache=metadata, logbias=throughput и sync=always, и это не было так до последних версий PVE. Я должен установить primarycache=metadata для всех томов ZFS, а не только для области swap, и Proxmox этого не делает. Я должен ограничить использование ОЗУ ARC, а Proxmox этого не делает, и документации по этому поводу очень мало. Я должен установить vm.min_free_kbytes не менее 512K, swappiness на ноль, и в любом случае никогда не использовать более 75% ОЗУ, а документации об этом нет, и swappiness не установлен на 0 по умолчанию установщиком. Размер ARC действительно должен быть динамическим, но я наблюдал случаи, когда, после установки arc_max во время работы, кэш никогда не освобождал ни одного байта, даже когда возникали ситуации OOM. Я считаю, что все эти настройки должны быть установлены по умолчанию (когда это возможно) и задокументированы в руководстве по ZFS для PVE, иначе не рекомендуется использовать ZFS в PVE, если у вас нет предварительных знаний о самом ZFS. Мне кажется, что ZFS в PVE — это работа в процессе, и он недостаточно стабилен для использования в производстве, если вы не обладаете достаточной квалификацией, чтобы настраивать его на основе своих знаний о самом ZFS. Сейчас мне интересно использование primarycache=metadata для тома, содержащего образы ВМ, я уже применил другие настройки и рекомендации к моему "тестовому серверу", который на самом деле является производственным, так что я очень осторожен в тестировании. Требует ли эта настройка перезагрузки? Улучшает ли она производительность, если у меня небольшой размер ARC (4 ГБ)?