Как измерить производительность кеша zfs с помощью кеша - PullRequest
0 голосов
/ 05 сентября 2018

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

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

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

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

Зпул выглядит так:

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

1 Ответ

0 голосов
/ 07 сентября 2018

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

Для теста чтения (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 (обычно называемое «ZIL», как вы упомянули в одном из комментариев). Я бы разделил ваш SSD на два раздела: один очень маленький для использования в качестве ZIL (нужно только хранить достаточно данных для кеширования ~ 10 секунд записи, если вы не настроили файловую систему), а другой - использовать оставшуюся часть диска как L2ARC.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...