Это меня озадачивает, и я не знаю, как разобраться, что на самом деле делает ZFS.
Я использую чистую установку FreeNAS 11.1 с быстрым пулом ZFS (импортированные зеркала на быстрых 7200) плюс одиночный UFS SSD для тестирования. Конфигурация практически "из коробки".
SSD содержит 4 файла размером 16-120 ГБ, скопированных с помощью консоли в пул. Пул дедуплицирован (стоит того: 4-кратное сохранение, размер 12 ТБ на диске), а в системе достаточно оперативной памяти (128 ГБ ECC) и быстрый Xeon. Памяти вполне достаточно — zdbпоказывает, что пул имеет в общей сложности 121 М блоков (по 544 байта на диске, по 175 байт в оперативной памяти), поэтому весь DDT составляет всего около 20,3 ГБ (около 1,7 ГБ на ТБ данных).
Но когда я копирую файлы в пул, я вижу это zpool iostat:
Он делает цикл длиной около минуты низкоуровневых чтений и кратковременный всплеск записей. Часть чтения показана на рисунке. Общая скорость записи для этой задачи также невелика — пул пуст на 45%/10 ТБ и изначально может писать со скоростью около 300–500 МБ/с.
Не зная, как проверить, я подозреваю, что низкоуровневые чтения связаны с чтением DDT и других метаданных, поскольку они не загружены предварительно в ARC (или постоянно вытесняются из ARC при записи данных файла). Возможно.
Может быть, он находит дедуплицированные попадания, поэтому там не так много записей, просто я не помню никаких дублированных версий этих файлов, и он делает то же самое с /dev/random, насколько я помню (я проверю это и скоро обновлю). Может быть. Понятия не имею.
Что я могу сделать, чтобы точнее разобраться в происходящем с целью его оптимизации?
Обновление оперативной памяти и дедупликации:
Я обновил Q, чтобы показать размер DDT после первоначального комментария. Дедуплицированная оперативная память часто указывается как 5 ГБ на ТБ x 4, но это основано на примере, который на самом деле не очень подходит для дедупликации. Вам нужно рассчитать количество блоков, умноженное на байты на запись. Часто цитируемое "x 4" — это просто "мягкий" предел по умолчанию (по умолчанию ZFS ограничивает метаданные до 25% ARC, если не указано использовать больше — эта система предназначена для дедупликации, и я добавил 64 ГБ, чтовсеможно использовать для ускорения кэширования метаданных).
Таким образом, в этом пуле zdbподтверждается, что для всего DDT потребуется всего 1,7 ГБ на ТБ, а не 5 ГБ на ТБ (всего 20 ГБ), и я с радостью отдам метаданным 70% ARC, а не 25% (80 ГБ из 123 ГБ).
При таком размере его не нужно выбрасывать.что-либокроме «мертвого» содержимого файлов от ARC. Поэтому я собираюсь на самом деле проверить ZFS, чтобы узнать, что, по его мнению, происходит, и чтобы я мог увидеть эффект любых изменений, которые я вношу, потому что я действительно очень удивлен его огромным объемом «чтений низкого уровня» и ищу способ проверить и подтвердить реальность того, что, по его мнению, он делает.