Я прочитал много информации о планировании требований к оперативной памяти для дедупликации ZFS. Я только что обновил ОЗУ моего файлового сервера, чтобы поддерживать некоторую очень ограниченную дедупликацию на zvol ZFS, на которой я не могу использовать моментальные снимки и клоны (так как они zvols отформатированы как другая файловая система), но в то же время будет содержать много дублированных данных.
Я хочу убедиться, что новое ОЗУ, которое я добавил, будет поддерживать ограниченную дедупликацию, которую я собираюсь сделать. В планировании мои цифры выглядят хорошо, но я хочу быть уверенным .
Как узнать текущий размер таблиц дедупликации ZFS (DDT) в моей работающей системе? Я прочитал эту ветку списка рассылки, но мне неясно, как они получают эти цифры. (Я могу опубликовать вывод zdb tankпри необходимости, но я ищу общий ответ, который может помочь другим)
источник
Прочитав оригинальную ветку электронной почты и ответ @ ewwhite, который прояснил ее, я думаю, что этот вопрос нуждается в обновленном ответе, так как ответ выше охватывает только половину его.
В качестве примера, давайте использовать вывод в моем пуле. Я использовал команду
zdb -U /data/zfs/zpool.cache -bDDD My_pool. В моей системе мне понадобился дополнительный-Uаргумент arg, чтобы найти файл кеша ZFS для пула, который FreeNAS хранит в другом месте, отличном от обычного; Вы можете или не должны делать это. Как правило, попробуйтеzdbбез-Uпредварительного, и если вы получите ошибку файла кэша, то используйтеfind / -name "zpool.cache"или аналогичный, чтобы найти нужный файл.Это был мой фактический вывод, и я интерпретировал его ниже:
Что все это значит, и определение фактического размера таблицы дедупликации:
В выходных данных отображаются две вложенные таблицы: одна для блоков, в которых существует дубликат ( DDT-sha256-zap-duplicate ), а другая для блоков, в которых нет дубликатов ( DDT-sha256-zap-unique ) /. В третьей таблице под ними приведены общие итоговые значения по обоим из них, а под ними есть итоговая строка. Глядя только на «итоговые» строки и сводку, мы получаем то, что нам нужно:
Давайте сделаем некоторые цифры хруста.
Счетчик блоков работает следующим образом: количество записей, связанных с дублирующимися блоками = 771295, количество записей, связанных с уникальными блоками = 4637966, общее количество записей в таблице DDT должно быть 771295 + 4637966 = 5409261. Таким образом, количество блоков в миллионах (двоичных миллионах то есть!) будет 5409261 / (1024 ^ 2) = 5,158 млн. В итоге мы находим всего 5,16 млн блоков .
Необходимая оперативная память работает следующим образом: 771295 записей для дублирующих блоков каждый занимает 165 байтов в оперативной памяти, а 4637966 записей для уникальных блоков каждый занимает 154 байта в оперативной памяти, поэтому общая оперативная память, необходимая для таблицы дедупликации прямо сейчас = 841510439 байт = 841510439 / (1024 ^ 2) МБайт = 803 МБ = 0,78 ГБ ОЗУ .
(Используемый размер на диске можно рассчитать аналогичным образом, используя цифры «размер на диске». Очевидно, что ZFS пытается эффективно использовать дисковый ввод-вывод и использует тот факт, что дисковое пространство, занимаемое DDT, не Обычно это не проблема. Похоже, что ZFS просто выделяет полный 512-байтовый сектор для каждой записи или что-то в том же духе, а не только 154 или 165 байт, чтобы сохранить его эффективность. Это может не включать какое-либо допущение для нескольких копии хранятся на диске, что обычно делает ZFS.)
Общий объем хранимых данных и выгода от его дедупликации. Из общей статистики DDT 715 ГБ (715 ГБ) данных хранятся с использованием всего 578 ГБ («578 ГБ») выделенного хранилища на дисках. Таким образом, наш коэффициент экономии места для дедупликации составляет (715 ГБ данных) / (578 ГБ пространства, используемого после его дедупликации) = 1,237 x, о чем нам говорит сводка («дедупликация = 1,24»).
источник