Насколько велика моя таблица дедупликации ZFS на данный момент?


21

Я прочитал много информации о планировании требований к оперативной памяти для дедупликации ZFS. Я только что обновил ОЗУ моего файлового сервера, чтобы поддерживать некоторую очень ограниченную дедупликацию на zvol ZFS, на которой я не могу использовать моментальные снимки и клоны (так как они zvols отформатированы как другая файловая система), но в то же время будет содержать много дублированных данных.

Я хочу убедиться, что новое ОЗУ, которое я добавил, будет поддерживать ограниченную дедупликацию, которую я собираюсь сделать. В планировании мои цифры выглядят хорошо, но я хочу быть уверенным .

Как узнать текущий размер таблиц дедупликации ZFS (DDT) в моей работающей системе? Я прочитал эту ветку списка рассылки, но мне неясно, как они получают эти цифры. (Я могу опубликовать вывод zdb tankпри необходимости, но я ищу общий ответ, который может помочь другим)

Ответы:


17

Вы можете использовать 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.2G хранится на диске в 37.5G места. Или 2,51 миллиона блоков на 2,35 миллиона блоков.

Чтобы узнать фактический размер таблицы, смотрите:

Записи DDT 2459286, размер 481 на диске, 392 в ядре

2459286 * 392 = 964040112 байт Разделите на 1024 и 1024, чтобы получить: 919,3 МБ в ОЗУ .


1
мои извинения за плотность ... в приведенном вами примере, как я могу определить, насколько велика таблица dedpue , в частности, сколько она использует RAM / L2ARC?
Джош

1
Смотрите обновленный пост.
13

1
Мне особенно нравится пример DDT @ ewwhite, потому что он также является звездным примером отношения, которое вообще исключает использование дедупликации. Я отправляю / извлекаю наборы данных в этом пуле, от дедупедированных наборов данных до недедедированных наборов данных, и считаю, что мне все еще достаточно мало, чтобы сделать это управляемым. :) Будьте осторожны, предполагая, что ваши zvols будут дедуплицировать. Как дедупликация на уровне блоков, единственная разница смещения может искажать все это. Если у меня есть какой-либо совет, то стоит передвинуть горы, чтобы протестировать набор производственных данных в лаборатории TEST / перед тем, как вводить дедупликацию ZFS в любую производственную среду.
Nex7

constantin.glez.de/blog/2011/07/zfs-dedupe-or-not-dedupe содержит полезную информацию о расчете ожидаемых выигрышей от дедупликации и ожидаемых затрат.
JLP

Этот ответ нуждался в обновлении, он не был достаточно полным. Смотрите подробный ответ ниже
Stilez

5

Прочитав оригинальную ветку электронной почты и ответ @ ewwhite, который прояснил ее, я думаю, что этот вопрос нуждается в обновленном ответе, так как ответ выше охватывает только половину его.

В качестве примера, давайте использовать вывод в моем пуле. Я использовал команду 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

Что все это значит, и определение фактического размера таблицы дедупликации:

В выходных данных отображаются две вложенные таблицы: одна для блоков, в которых существует дубликат ( DDT-sha256-zap-duplicate ), а другая для блоков, в которых нет дубликатов ( DDT-sha256-zap-unique ) /. В третьей таблице под ними приведены общие итоговые значения по обоим из них, а под ними есть итоговая строка. Глядя только на «итоговые» строки и сводку, мы получаем то, что нам нужно:

Размер DDT для всех блоков, которые появляются более одного раза («DDT-sha256-zap-duplicate») :
771295 entries, size 512 bytes on disk, 165 bytes in RAM ("core")

Размер DDT для блоков, которые являются уникальными («DDT-sha256-zap-unique») :
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»).

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.