Я дал ссылку на комментарий основного контрибьютора Brian Behlendorf, в котором он разъяснял требования к ОЗУ, касающиеся первого поста в тикете (проблема с производительностью при увеличении L2ARC). Проблема с mirror не касается обсуждаемого нами.
Все ли верно понимаю?
Всё верно, l2arc можете увеличивать по надобности без даунтайма, если ssd позволяет. arc_meta_limit стоит трогать только если выделенный объём l2arc не заполнится.
Если вы имеете в виду установку root раздела системы на ZFS, то пока она включена только в инсталлятор Proxmox. При этом сам пакет с ZFS уже есть во многих репозиториях (Debian, Ubuntu, Arch, Gentoo, Fedora, Centos), ручками ставится без проблем.
Добавлю, что в релизе 0.7 требования к ОЗУ сильно оптимизированы, и в вашем случае может помочь (но он ещё в стадии тестирования, без бекапов ставить не рекомендую).
Как давно тестировали? В будущем релизе ZoL 0.7 включено множество оптимизаций производительности, которые, кстати, сразу портируются в OpenZFS (то есть проблемы уже не в реализации на Linux, основную проблему взаимодействия с ОЗУ уже решили в 0.7).
К сожалению, серебряной пули в этом вопросе не существует, и ZFS требует подготовки перед использованием в продакшене (как, собственно, и любая другая ФС).
Нашёл тикет, касающийся данного вопроса. Проблема квалифицирована не как баг, соответственно у неё нулевой приоритет.
К сожалению, ZFSonLinux развивается в основном за счёт энтузиастов с упором на продакшн, удобства для десктопов только начинают получать какое-то внимание. Всегда рады пулл реквестам!
Давайте вспомним, что это CoW, да, ей даже при удалении надо сначала записать.
Плюс добавлю, что не рекомендуется заполнять пул больше, чем на 80%, дальше начнутся проблемы с фрагментированием. Последнее, что стоит делать с CoW — заполнять её на 100%, уже на 90% мониторинг обязан орать.
Стоит уточнить, что стабильный патч Nexenta ещё не выпущен.
Расчёт простой — на каждый блок в L2ARC нужно ~200байт ОЗУ, для виртуализации скорее всего вы будете использовать zvol с volblocksize=8kb, соответственно на 100гб L2ARC потребуется около 2.5гб ОЗУ, на практике будет меньше.
Если у вас уже есть ssd, то проведите бенчмарк, иначе для начала просто настройте ограничение на ARC и попробуйте. Главное правильно настроить proxmox, volblocksize должен соответствовать блоку гостевой системы.
Производительность будет зависеть от особенностей ваших данных, если горячие данные поместятся в ваши 3гб ОЗУ, то это лучше, чем L2ARC.
Вот пример расчёта количества ОЗУ, требуемого для L2ARC.
Я бы советовал потратить деньги на ОЗУ, L2ARC на малых конфигурациях не особо вам поможет. Также стоит учесть, что пока L2ARC не сохраняет состояние между перезагрузками, и каждый раз требует «прогрева».
Технически, существует возможность откатиться на более ранние транзакции, которые могут быть уже повреждены — вам поможет вот этот патч. К сожалению, это не гарантированный вариант. Удачи вам!
Рекомендую все действия производить над копией массива.
Я дал ссылку на комментарий основного контрибьютора Brian Behlendorf, в котором он разъяснял требования к ОЗУ, касающиеся первого поста в тикете (проблема с производительностью при увеличении L2ARC). Проблема с mirror не касается обсуждаемого нами.
Всё верно, l2arc можете увеличивать по надобности без даунтайма, если ssd позволяет. arc_meta_limit стоит трогать только если выделенный объём l2arc не заполнится.
Если я правильно понял, в ZoL есть аналог fmd — ZED.
Не спорю, интерес именно в накладных расходах разных реализаций.
Да.
Вот интересная информация по этой теме.
Добавлю, что в релизе 0.7 требования к ОЗУ сильно оптимизированы, и в вашем случае может помочь (но он ещё в стадии тестирования, без бекапов ставить не рекомендую).
Эх, вот бы усилия Oracle да объединить с OpenZFS…
К сожалению, серебряной пули в этом вопросе не существует, и ZFS требует подготовки перед использованием в продакшене (как, собственно, и любая другая ФС).
К сожалению, ZFSonLinux развивается в основном за счёт энтузиастов с упором на продакшн, удобства для десктопов только начинают получать какое-то внимание. Всегда рады пулл реквестам!
Плюс добавлю, что не рекомендуется заполнять пул больше, чем на 80%, дальше начнутся проблемы с фрагментированием. Последнее, что стоит делать с CoW — заполнять её на 100%, уже на 90% мониторинг обязан орать.
Стоит уточнить, что стабильный патч Nexenta ещё не выпущен.
Расчёт простой — на каждый блок в L2ARC нужно ~200байт ОЗУ, для виртуализации скорее всего вы будете использовать zvol с volblocksize=8kb, соответственно на 100гб L2ARC потребуется около 2.5гб ОЗУ, на практике будет меньше.
Если у вас уже есть ssd, то проведите бенчмарк, иначе для начала просто настройте ограничение на ARC и попробуйте. Главное правильно настроить proxmox, volblocksize должен соответствовать блоку гостевой системы.
Производительность будет зависеть от особенностей ваших данных, если горячие данные поместятся в ваши 3гб ОЗУ, то это лучше, чем L2ARC.
Я бы советовал потратить деньги на ОЗУ, L2ARC на малых конфигурациях не особо вам поможет. Также стоит учесть, что пока L2ARC не сохраняет состояние между перезагрузками, и каждый раз требует «прогрева».
В вашем примере могла сказаться фрагментация, ZFS по объективным причинам любит большое наличие свободного места.
Рекомендую все действия производить над копией массива.
В случае несжимаемых данный ZFS не проводит сжатие, можете об этом не волноваться.