Итак, недавно при тестировании системы ZoL мы обнаружили низкую производительность случайного и последовательного чтения и низкую производительность случайной записи на наших SSD.
Наша система представляет собой полосу из двух твердотельных накопителей Samsung 1 ТБ 850Evo для тестирования производительности ZFS, и это было ужасно по сравнению с LVM: чтение происходит медленнее, чем с жестких дисков, а объем записи не соответствует ожидаемым 1,7 ГБ, которые мы получаем на LVM. Это странно, потому что наш сервер резервного копирования FreeBSD имеет медленные жесткие диски и твердотельные накопители старого типа и работает лучше в том же тесте.
Однако система несколько лишена оперативной памяти (zfs получает 4 ГБ для arc, а все остальное используется виртуальными машинами), однако без кеша и без синхронизации производительность по-прежнему даже близко не к чему.
Поэтому мы планируем покупать более новые системы на базе AMD Epyc и настраивать либо полный NVMe, либо NVMe с твердотельными накопителями с отключением кеша, чтобы хотя бы немного освободить оперативную память от ZFS (мы хотим, чтобы для всего было использовано не более 10 ГБ). На самом деле нам не нужны все функции безопасности ZFS, кроме контрольной суммы (но с SSD это кажется избыточным, поскольку SSD работает с внутренней системой контрольной суммы), поэтому SSD будут полосой vdevs.
Мы предпочитаем ZFS для zle на zvols с тонким предоставлением, а также простоту создания моментальных снимков и инкрементного резервного копирования в удаленную систему (которая также запускает ZFS).
Однако борьба за производительность тяжелая ...
Был бы очень признателен за любой совет
Во-первых, контрольная сумма ZFS не избыточный: это сквозная контрольная сумма (ОЗУ на физический носитель), а контрольная сумма HDD / SSD используется как контроль ошибок "внутреннего носителя". Чтобы иметь что-то подобное с классической файловой системой, вы было использовать T10 / DIF-совместимые диски и контроллеры, которых нет в устройствах SATA (вы вынуждены использовать SAS SSD, которые намного дороже).
Тем не менее, низкая производительность записи с ZVOL обычно связана с очень маленьким размером блока по умолчанию 8 КБ, который достаточно мал, чтобы значительно увеличить накладные расходы на метаданные, но недостаточно мал, чтобы предотвратить циклы чтения-изменения-записи для операций записи 4 КБ.
Другая проблема с потребительскими дисками SATA SSD (такими как ваш Samsung 850 EVO) заключается в том, что у них нет кеша с защитой от потери мощности, поэтому ZFS постоянно сбрасывает их для записи метаданных. и синхронная запись данных.
В любом случае, вам действительно следует предоставить нам более подробную информацию о вашей методологии тестирования и реальной ожидаемой рабочей нагрузке, чтобы получить точный ответ.
Производительность низкая, потому что значения по умолчанию ZFS не идеальны для того, что вы делаете. У тебя есть что-нибудь в /etc/modprobe.d/zfs.conf? Если нет, то это требует некоторой настройки.
volblocksize=128KВ частности, если кто-то использует докер (как я), UFS не является настоящим производственным решением, если вы регулярно строите или имеете много контейнеров и томов (как я :)).
Поскольку docker может использовать серверную часть ZFS, все равно будут некоторые люди, которые захотят использовать SSD и Optane в своей системе с ZFS.
@Andrew Я столкнулся с некоторыми из тех же проблем, что и вы, и мне пришлось исправить свои проблемы с огромной оперативной памятью (32 ГБ для ARC). общий сервер теперь имеет 128 ГБ ОЗУ, но может обеспечивать потрясающую производительность, на которую способны немногие системы.
Другая группа людей - это люди, использующие полосы ZFS на AWS для обхода BurstIO - по сути, все ваши SSD-тома EBS просто ждут, чтобы начать показывать производительность, подобную SATA 5.4K, как только ваш пакетный баланс снизится. В такой ситуации я вижу, что ZFS внезапно переключается на большой последовательный ввод-вывод, чтобы не отставать. так что пока мои приложения контролируют пакетный баланс и сокращают ввод-вывод, ZFS будет пытаться сохранить разум.
Я ожидаю, что нечто очень похожее испытают люди, работающие с VMWare, когда их многоуровневый гипервиртуализированный сверхразумный массив хранения данных начинает пытаться динамически управлять производительностью в тяжелые времена большого количества операций ввода-вывода и увеличения задержки.
Мне известны конструкции систем хранения, в которых в качестве пула записи используется по существу большой кэш ОЗУ - это в основном означает, что хранилище сообщает, что все записи являются попаданиями в кеш, а перенос на диск происходит позже.
По крайней мере, я знаю, что с ZFS это сделали настоящие программисты.
Таким образом, ZFS на твердотельных накопителях еще имеет некоторую ценность :) - это зависит от того, с какими проблемами вы столкнетесь.
Если кому интересно. Мы думаем, что основная проблема - это оперативная память (наш ARC ограничен 4 ГБ, поэтому все остальное съедает система). На данный момент дело с ZFS - она не готова для SSD и / или NVMe. Он был создан для жестких дисков, медленных и громоздких, с их глупыми головками, механикой и предсказуемыми проблемами.
С SSD и NVMe ZFS выполняет глупые вещи, которые им не нужны, и не делает то, что им действительно нужно. Когда была изобретена ZFS, о энергонезависимой оперативной памяти больше не думали о кеш-памяти.
Теперь мы можем разместить 4x pcie SSD в системе с 4 ТБ пространства.
В таком случае есть 2 способа справиться с этим. Либо дайте ему достаточно памяти, и пусть он правильно работает на ваших SSD с накладными расходами, которые он предоставляет. Или не использовать ZFS.
Обидно, потому что его структурные преимущества довольно хороши. Но он не может правильно обрабатывать твердотельные накопители без более высокого использования оперативной памяти, чем с жесткими дисками, потому что все настройки и конфигурация говорят ему, что "базовые системы медленные, необходим кеш, чтение мало, запись большая и последовательная", когда твердотельные накопители быстрые, не нужны кеш, может читать большие и писать большие и делать случайные правильно. С Optane такие проблемы будут очевидны.
Вещи, которые более или менее не нужны, - это обширное кэширование, контрольная сумма каждого файла на уровне записи (это не имеет смысла, потому что, если у вас есть битрот на уровне SSD, вы должны выбросить весь диск, так как для такая система, потому что у нее может быть сломанный контроллер, разрушающий все ваши данные, это похоже на плохую RAM). SIL вообще не нужен. ARC также бесполезен, особенно с приводами Optane (он увеличивает накладные расходы на ЦП и ОЗУ). Размер записи должен быть полностью ограничен для записи в транзакциях, которые понимает диск.
Или просто используйте LVM для подготовки KVM в системах. Тонкая подготовка не идеальна, но, по крайней мере, вам не нужно тратить чрезвычайно ценную оперативную память на то, чтобы ваши твердотельные накопители работали на должном уровне.