Я прочитал много информации о планировании требований к оперативной памяти для дедупликации ZFS. Я только что обновил оперативную память своего файлового сервера для поддержки очень ограниченного дедупликации на zvols ZFS, на которых я не могу использовать снимки и клоны (поскольку они zvols отформатированы как другая файловая система), но будут содержать много дублированных данных.
Я хочу убедиться, что добавленная мной новая оперативная память будет поддерживать ограниченную дедупликацию, которую я собираюсь делать. При планировании мои цифры выглядят хорошо, но я хочу быть конечно.
Как я могу сказать ток размер таблиц дедупликации ZFS (DDT) в моей действующей системе? Я читаю эта ветка списка рассылки но я не понимаю, как они достигают этих цифр. (Я могу опубликовать вывод zdb tank если необходимо, но я ищу общий ответ, который может помочь другим)
Вы можете использовать zpool status -D poolname команда.
Результат будет выглядеть примерно так:
root@san1:/volumes# zpool status -D vol1
pool: vol1
state: ONLINE
scan: scrub repaired 0 in 4h38m with 0 errors on Sun Mar 24 13:16:12 2013
DDT entries 2459286, size 481 on disk, 392 in core
bucket allocated referenced
______ ______________________________ ______________________________
refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE
------ ------ ----- ----- ----- ------ ----- ----- -----
1 2.23M 35.6G 19.0G 19.0G 2.23M 35.6G 19.0G 19.0G
2 112K 1.75G 1005M 1005M 240K 3.75G 2.09G 2.09G
4 8.03K 129M 73.8M 73.8M 35.4K 566M 324M 324M
8 434 6.78M 3.16M 3.16M 4.61K 73.8M 35.4M 35.4M
16 119 1.86M 811K 811K 2.33K 37.3M 15.3M 15.3M
32 24 384K 34.5K 34.5K 1.13K 18.1M 1.51M 1.51M
64 19 304K 19K 19K 1.63K 26.1M 1.63M 1.63M
128 7 112K 7K 7K 1.26K 20.1M 1.26M 1.26M
256 3 48K 3K 3K 1012 15.8M 1012K 1012K
512 3 48K 3K 3K 2.01K 32.1M 2.01M 2.01M
1K 2 32K 2K 2K 2.61K 41.7M 2.61M 2.61M
2K 1 16K 1K 1K 2.31K 36.9M 2.31M 2.31M
Total 2.35M 37.5G 20.1G 20.1G 2.51M 40.2G 21.5G 21.5G
Важными полями являются Общее количество выделенные блоки и Общее количество ссылочные блоки. В приведенном выше примере у меня низкий коэффициент дедупликации. 40,2 ГБ хранится на диске в 37,5 ГБ пространства. Или 2,51 миллиона блоков на площади 2,35 миллиона блоков.
Чтобы узнать фактический размер таблицы, см.:
Записи ДДТ 2459286, размер 481 на диске, 392 в ядре
2459286 * 392 = 964040112 байт. Разделите на 1024 и 1024, чтобы получить: 919,3 МБ ОЗУ.
После прочтения исходной цепочки писем и @ ewwhite's ответ, который прояснил это, я думаю, что на этот вопрос нужен обновленный ответ, так как ответ выше охватывает только половину.
В качестве примера возьмем вывод из моего пула. Я использовал команду zdb -U /data/zfs/zpool.cache -bDDD My_pool. В моей системе мне требовалось дополнительное -U arg, чтобы найти файл кэша ZFS для пула, который FreeNAS хранит в другом месте, чем обычно; вам может понадобиться это сделать, а может и нет. Вообще попробуй zdb без -U сначала, и если вы получите ошибку файла кеша, используйте find / -name "zpool.cache" или аналогичный, чтобы найти нужный файл.
Это был мой фактический результат, и я интерпретировал его ниже:
DDT-sha256-zap-duplicate: 771295 entries, size 512 on disk, 165 in core
bucket allocated referenced
______ ______________________________ ______________________________
refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE
------ ------ ----- ----- ----- ------ ----- ----- -----
2 648K 75.8G 68.6G 68.8G 1.39M 165G 149G 149G
4 71.2K 8.07G 6.57G 6.62G 368K 41.7G 34.1G 34.3G
8 28.1K 3.12G 2.34G 2.36G 281K 31.0G 23.1G 23.4G
16 5.07K 424M 232M 241M 110K 9.10G 5.06G 5.24G
32 1.09K 90.6M 51.8M 53.6M 45.8K 3.81G 2.21G 2.28G
64 215 17.0M 8.51M 8.91M 17.6K 1.39G 705M 739M
128 38 2.12M 776K 872K 6.02K 337M 118M 133M
256 13 420K 21.5K 52K 4.63K 125M 7.98M 18.5M
512 3 6K 3K 12K 1.79K 3.44M 1.74M 7.16M
1K 1 128K 1K 4K 1.85K 237M 1.85M 7.42M
2K 1 512 512 4K 3.38K 1.69M 1.69M 13.5M
DDT-sha256-zap-unique: 4637966 entries, size 478 on disk, 154 in core
bucket allocated referenced
______ ______________________________ ______________________________
refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE
------ ------ ----- ----- ----- ------ ----- ----- -----
1 4.42M 550G 498G 500G 4.42M 550G 498G 500G
DDT histogram (aggregated over all DDTs):
bucket allocated referenced
______ ______________________________ ______________________________
refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE
------ ------ ----- ----- ----- ------ ----- ----- -----
1 4.42M 550G 498G 500G 4.42M 550G 498G 500G
2 648K 75.8G 68.6G 68.8G 1.39M 165G 149G 149G
4 71.2K 8.07G 6.57G 6.62G 368K 41.7G 34.1G 34.3G
8 28.1K 3.12G 2.34G 2.36G 281K 31.0G 23.1G 23.4G
16 5.07K 424M 232M 241M 110K 9.10G 5.06G 5.24G
32 1.09K 90.6M 51.8M 53.6M 45.8K 3.81G 2.21G 2.28G
64 215 17.0M 8.51M 8.91M 17.6K 1.39G 705M 739M
128 38 2.12M 776K 872K 6.02K 337M 118M 133M
256 13 420K 21.5K 52K 4.63K 125M 7.98M 18.5M
512 3 6K 3K 12K 1.79K 3.44M 1.74M 7.16M
1K 1 128K 1K 4K 1.85K 237M 1.85M 7.42M
2K 1 512 512 4K 3.38K 1.69M 1.69M 13.5M
Total 5.16M 638G 576G 578G 6.64M 803G 712G 715G
dedup = 1.24, compress = 1.13, copies = 1.00, dedup * compress / copies = 1.39
Что все это означает и определение фактического размера таблицы дедупликации:
В выходных данных показаны две подтаблицы, одна для блоков, в которых существует дубликат (ДДТ-sha256-zap-duplicate) и один для блоков, где нет дубликатов (ДДТ-sha256-zap-unique) /. В третьей таблице под ними приводится общая сумма по обоим из них, а под ней находится итоговая строка. Глядя только на "итоговые" строки и сводку, мы получаем то, что нам нужно:
Размер ДДТ для всех блоков, которые встречаются более одного раза ("ДДТ-sha256-zap-duplicate"):
771295 entries, size 512 bytes on disk, 165 bytes in RAM ("core")Размер DDT для уникальных блоков («ДДТ-ша256-зап-уникальный»):
4637966 entries, size 478 bytes on disk, 154 bytes in RAM ("core")Общая статистика ДДТ для всех записей ДДТ, дубликаты + уникальны («Гистограмма ДДТ, агрегированная по всем ДДТ»):
allocated referenced (= disk space actually used) (= amount of data deduped into that space) ______ ______________________________ ______________________________ blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE Total 5.16M 638G 576G 578G 6.64M 803G 712G 715GРезюме:
dedup = 1.24, compress = 1.13, copies = 1.00, dedup * compress / copies = 1.39
Давайте займемся обработкой чисел.
Счетчик блоков работает так: Количество записей, связанных с повторяющимися блоками = 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»).