Как измерить производительность кеша zfs с кеш-диском

Я пытаюсь сравнить разные файловые системы, большинство из которых имеют функции кеширования / многоуровневого хранилища, но пока что это не работает должным образом. (кстати, я знаю, что это может быть неправильный сайт, но когда я искал zfs, большинство результатов SE были в stackoverflow, поэтому было неплохо спросить здесь)

При тестировании zfs я создал один пул с основным диском / разделом и другим диском (ssd), добавленным в качестве кеша. Основной диск / раздел был около 200 ГБ, SSD 120 ГБ. Это правильно отображается в zpool.

Затем я запустил набор тестов phoronix с iozone или iozone отдельно. После некоторого первоначального незнания я остановился на phoronix-test-suite run-default pts/iozone, который затем запускал только на hdd, только на ssd и разделе hdd с ssd в качестве кеша. Причем на двух ноутах, у которых для сравнения есть ssds. В тесте с zfs + cache практически не было разницы в использовании только жесткого диска. Это было действительно очень медленно. И я убедился, что установил рабочий каталог в zpool и проверил, что там был создан временный файл, а также проверил zpool iostat, чтобы убедиться, что пул работает. Теперь, хотя я мог подозревать более низкие результаты, я бы надеялся, что скорости должны быть, по крайней мере, несколько ниже, особенно с таким «легким» тестом, как этот, который просто выполняет 3 прогона чтения записей размером 1 МБ из файла размером 8 ГБ, а затем 3 цикла записи записей размером 1 МБ из файла размером 8 ГБ.

Теперь, может быть, из-за того, как работает кеш zfs и аналогичные - они не могут быть захвачены таким простым тестом - но тогда какой тест будет хорошим для выявления преимуществ кеша? Однако, поскольку тестовый файл легко помещается в кеш-память ssd, почему он сначала не записывается туда и не передается обратно на жесткий диск в фоновом режиме?

Zpool выглядит так:

pool: ztest
state: ONLINE
scan: none requested
config:

    NAME        STATE     READ WRITE CKSUM
    ztest       ONLINE       0     0     0
      sdb7      ONLINE       0     0     0
    cache
      sdc       ONLINE       0     0     0

errors: No known data errors

person step21    schedule 05.09.2018    source источник
comment
Можете ли вы добавить вывод zpool status, чтобы мы могли видеть настройку? Похоже, вы либо неправильно настроили свой пул, либо тест не проверяет то, что вы ожидали, и было бы неплохо убедиться, что это не первое.   -  person Dan    schedule 06.09.2018
comment
Я добавил описание пула. Это было создано с помощью zpool create ztest /dev/sdb7 cache /dev/sdc на основе найденных мной документов. После прочтения кажется, что кеш может быть только кешем чтения (хотя это все равно не объясняет ужасную производительность чтения), а для кеша записи потребуется дополнительно zil. Но на некоторых из тех же страниц также было сказано, что ZIL будет иметь смысл только для больших объемов хранения или огромных серверов / определенных рабочих нагрузок. Что кажется странным, поскольку в других случаях люди описывают zfs как полезные практически для всего.   -  person step21    schedule 06.09.2018


Ответы (1)


Вот мои предположения о несоответствии ожидания / реальности:

Для теста чтения (3 прогона чтения записей размером 1 МБ из файла размером 8 ГБ)

Кэш-устройство ZFS (обычно называемое «L2ARC») заполняется при записи или чтении блока. Из вашего описания я предполагаю, что тест записывает файл один раз, а затем читает его последовательно 3 раза. Я ожидаю, что L2ARC сделает копию блоков на вашем устройстве кэш-памяти во время первой записи или, по крайней мере, когда вы впервые читаете данные. (Хотя обратите внимание, что L2ARC еще не сохраняется при перезагрузках, потому что карта того, что находится на диске, хранится только в памяти - своего рода глупое ограничение, но, вероятно, не то, что влияет на ваш тест.)

Используете ли вы zfs set secondarycache=all для кеширования всех блоков данных, а не только metadata блоков? (Чтобы устранить неоднозначность / объяснить название, свойство primarycache имеет аналогичные настройки для кеша в ОЗУ, также известного как «ARC».)

Чтобы проверить, используется ли L2ARC во время теста, вы можете посмотреть arcstat данные - вас интересуют следующие статистические данные:

"l2hits":     [6, 1000, "L2ARC hits per second"],
"l2miss":     [6, 1000, "L2ARC misses per second"],

С описанным вами тестом я ожидаю увидеть очень высокий процент совпадений (при условии, что ваш SSD> 8 ГБ).

Для теста записи (3 цикла записи записей размером 1 МБ из файла размером 8 ГБ)

Это поможет только в том случае, если вы также добавите устройство SSD log (обычно называемое «ЗИЛ», как вы упомянули в одном из комментариев). Я бы разделил ваш SSD на два раздела: один очень маленький для использования в качестве ZIL (должен хранить достаточно данных для кеширования ~ 10 секунд записи при условии, что вы не настроили файловую систему), и один, использующий остальную часть диска в качестве L2ARC.

Если обратиться к совету, который вы получили о том, чтобы не использовать ZIL, если у вас нет большого мощного сервера, я не думаю, что есть какие-либо причины не использовать ZIL в маленькой системе. Я предполагаю, что это связано с небольшим дополнительным SSD, который можно было бы использовать для кеша чтения, но он не использует дополнительную оперативную память или заметный объем дополнительного процессора, поэтому эффективно он должен ускорить ваши задержки записи / пакетную пропускную способность без каких-либо неблагоприятных последствий. побочные эффекты.

person Dan    schedule 06.09.2018
comment
Спасибо за ответ. Вторичный кэш установлен на все, он говорит, что это значение по умолчанию. Я переключился с использования phoronix-test-suite на запуск аналогичного теста вручную, поскольку он позволяет упростить переключение на запуск только чтения и обеспечение использования того же файла. Это сделало результаты более предсказуемыми, и они улучшились при последующих запусках, но все же больше соответствовали производительности жесткого диска (68,5 МБ / с при чтении). Это, кажется, подтверждается тем фактом, что arcstat -f l2hits,l2miss, похоже, вообще не работал во время прогонов только для чтения, показывая только 1-5 и в основном ноль во время исходной записи / чтения. - person step21; 07.09.2018
comment
Есть идеи для этого? С ЗИЛом ​​пока не тестировал. - person step21; 07.09.2018
comment
Я прочитал еще несколько подробностей о L2ARC, и, видимо, он не такой детерминированный, как я думал. (См. здесь для получения подробной информации от первоначального автора. Похоже, вам просто нужно, чтобы система работала, читая эти блоки немного дольше, чтобы увидеть выгоду. В этой статье также упоминается, что L2ARC не поддерживает последовательные рабочие нагрузки; Я прочитал код и не нашел никаких положений по этому поводу. Может, вырвалось, не уверен. - person Dan; 07.09.2018
comment
Ммм, я могу скопировать систему, или iozone также имеет возможность выполнять произвольное чтение / запись (из того же файла) в течение определенного периода времени, так что, возможно, это может быть вариантом. Как вы думаете, с какого момента что-то считается последовательным? Я читал в документах bcache (связанных с кешированием), что они по умолчанию обрабатывают последовательные (что, как я предполагаю, означает большие, непрерывные) записи по-разному, но в зависимости от размера это может быть отключено или не имеет смысла, как когда я Если у вас есть ssd объемом 120 ГБ или более (например, жесткий диск емкостью 2–4 ТБ), то почему бы не кэшировать этот файл размером 8 ГБ перед его переносом на жесткий диск? - person step21; 07.09.2018
comment
Дополнительная информация: здесь pthree.org/2013/04/19/ ZIL описывается больше как резервная копия, которая просто перемещает ZIL с жесткого диска / оперативной памяти на SSD, но по сути является всего лишь резервной копией, так что она просто используется если система прервана и данные еще не записаны на жесткий диск, но в противном случае никогда не используются. - person step21; 08.09.2018
comment
Мои собственные текущие испытания еще более странные - теперь я создал новый кеш пула и zil, начав с копирования на него работающего Linux, а затем посмотрел, как это работает. Во время копирования слежу с помощью iostat и поэтому кажется, что ЗИЛ не используется, даже для резервного копирования. При этом показано, что кеш медленно заполняется. Это кажется странным, поскольку к файлам нельзя обращаться. Для копирования я использовал rsync, может быть, он читает файлы как подтверждение, и поэтому они перемещаются в кеш? Снимок экрана iostat: imgur.com/a/qAPzFSC (также я пока приму ваш ответ, но Я рассматриваю это как продолжающееся расследование) - person step21; 08.09.2018
comment
Статья, на которую я ссылался выше, касалась поведения кеша, которое вы наблюдаете - L2ARC заполняется асинхронным копированием данных с ARC на SSD. Все записи попадают в ARC, если есть место (потому что почему бы не использовать эту оперативную память, если она у вас есть?), Поэтому он просто постепенно кэширует материал, который был недавно написан. Что касается того, что вы сказали о ЗИЛе, я думаю, что «резервная» аналогия немного неверна. Это не журнал записи, который требуется для правильности (как, например, ext4) - это способ фиксации синхронной записи с низкой задержкой, потому что нормальный путь записи является асинхронным. - person Dan; 08.09.2018
comment
Чтобы объяснить, почему ZIL не используется, rsync может не выполнять синхронизирующие записи в ZFS, поэтому ZFS предпочитает использовать обычный путь асинхронной записи. Это более эффективно с его точки зрения, поскольку ему не нужно записывать данные дважды (один раз в ZIL и один раз в основной пул). - person Dan; 08.09.2018
comment
Спасибо за ваши комментарии. Я не имел в виду резервное копирование как «журнал записи», но на основе описания материал сначала записывается в ZIL (независимо от RAM или SSD), а затем удаляется оттуда только после записи на устройство резервного копирования. Что касается неиспользуемого ЗИЛа, я видел это также в тестах iozone и fio. Пока что кажется, что bcache или bcachefs гораздо более актуальны для моего варианта использования. Тем более, что также при первой загрузке zfs по какой-то причине решил провести очистку, поэтому загрузка заняла вечность (и я не видел этого из-за отсутствия консоли фреймбуфера по не связанным причинам). - person step21; 13.09.2018
comment
Есть ли какой-нибудь тест или рабочая нагрузка, где вы знаете, что он подходит для zfs и будет использовать как кеш, так и ZIL? - person step21; 13.09.2018