Обновление: поскольку размер записи по умолчанию равен 128 КБ, объем данных, считываемых тестовой программой, намного больше, чем ARC в системе 8 ГБ, и все же немного больше, чем ARC в системе 16 ГБ. Уменьшение размера записи позволяет читать меньше данных и, следовательно, подходит для ARC. Я недооценивал размер считываемых данных, влияние на это размера записи и, следовательно, делал некоторые плохие выводы. Пока что отключение предварительной выборки, похоже, не имеет большого значения в этом случае, хотя я собираюсь попробовать все параметры записи с включенной предварительной выборкой и без нее.
Эта загрузка аналогична сценарию IMAP / Maildir со множеством каталогов, множеством файлов и потенциально только небольшими объемами данных, считываемых из каждого файла.
Я тестировал FreeBSD 10 и Fedora 19 с zfsonlinux. Я тестировал различные файловые системы Linux, такие как extX / xfs / jfs и даже btrfs. На FreeBSD я также тестировал, используя собственную файловую систему ufs. Моя рабочая нагрузка - просто сканировать огромную музыкальную коллекцию с помощью amarok / winamp / и т. Д. Моя тестовая программа - amarok_collectionscanner, потому что ее легко запустить из командной строки. Шаблон всегда один и тот же. Первоначальный запуск сканера сбора занимает около 10 минут в зависимости от файловой системы, но ZFS работает аналогично файловым системам, отличным от ZFS.
Последующие запуски сканирования выполняются невероятно быстро с использованием файловой системы, отличной от zfs, обычно около 30 секунд. При последующих запусках ZFS вносит лишь незначительные улучшения. Из просмотра iostat также очевидно, что после первоначального запуска в файловой системе, отличной от ZFS, ОС не касается диска. Это все в кеше файловой системы.
Использование кэша SSD для ZFS сокращает время, но оно никогда не приближается к 30 секундам.
Почему ZFS не кэширует эту нагрузку? Одна из возможностей, которую я исследовал, заключалась в том, что размер ARC был ограничен меньшим, чем разрешено использовать файловой системе, отличной от ZFS, для кэширования. Я снова протестировал на машине с большим объемом памяти, доступным для ARC, чем вся доступная память в первой тестовой системе, и цифры остались прежними.
Надеюсь найти / создать рецепт fio, который дублирует такую нагрузку. По сути, потребуется создать тысячи небольших файлов, сканировать все каталоги в поисках файлов, открывать каждый файл и читать небольшой объем данных из каждого из них. Это как худшая база данных в мире! Я, вероятно, протестирую OpenIndiana следующим, но ожидаю, что результаты будут такими же.
Набор данных составляет 353 ГБ и 49 000 файлов. В тестовых системах было 8-16 ГБ оперативной памяти. Конфигурация zpool не имела большого значения, но тесты, которые мне интересны, всегда были одним целым диском. Среди прочих приводов я использовал ST3500630AS и WDC WD20EZRX-00D8PB0. Приводы почти не имели значения. Объем оперативной памяти или скорость процессоров практически не имели значения. Только используемая файловая система заметно изменила результаты, и эти различия были весьма существенными, как я отмечал выше. На самом деле у меня есть горы точек данных относительно различных параметров файловой системы, которые я пробовал, и это некоторые из переменных, которые я проверял: конфигурации рейда mdadm (0 и 1), конфигурации zpool, зеркальное отображение и полоса zfs recordsize Размер блока mdadm файловой системы
На одном диске ST3500630AS я получил эти числа для параметров файловой системы по умолчанию для следующих файловых систем. Это было в Fedora 19, 8 ГБ ОЗУ, ядро 3.11.10-200, ZFS 0.6.2-1. Значения указаны в секундах. Последующие проверки выполнялись без попытки очистить кеш.
ZFS: 900, 804, 748, 745, 743, 752, 741
btrfs: 545, 33, 31, 30, 31, 31
ext2: 1091, 30, 30, 30, 30, 30...
ext3: 1014, 30, 30, 30, 30, 30...
ext4: 554, 31, 31, 32, 32, 31, 31...
jfs: 454, 31, 31,31,31...
xfs: 480, 32, 32, 32, 32 ,31 ,32, etc.
На FreeBSD 10 один диск WD20EZRX-00D8PB0, более быстрая машина, 16 ГБ памяти, ARC позволяет увеличить до 12 ГБ:
ufs: 500, 18, 18...
zfs: 733, 659, 673, 786, 805, 657
Хотя указанные выше переменные иногда влияли на начальное сканирование данных в холодном кэше, все последующие запуски выглядят одинаково. Стандартные файловые системы кешируют все это, и поэтому, пока ничто другое не обрабатывает кеш, работают молниеносно. ZFS не демонстрирует такого поведения.
Начните с отключения atime если еще не сделано.
Вы также можете изучить настройку primarycache=metadata влияние.
На FreeBSD установите sysutils / zfs-stats
инструмент zfs-mon, который является частью этого пакета, предоставит вам подробную информацию о соотношениях попаданий / пропусков кеша для каждого из различных типов кешей в ZFS (ARC, ARC Metadata, ZFETCH, Prefetch и т. д.).
Также может помочь 'zpool iostat 1' при сканировании
По умолчанию кэш метаданных ограничен 1/4 от ARC, вы можете настроить это значение с помощью настраиваемого vfs.zfs.arc_meta_limit loader.conf
В FreeBSD 10 статистика ARC включена в «верхнюю часть», и наблюдение за тем, как эти значения меняются во время сканирования, может дать некоторое представление.