Berapa besar tabel dedupe ZFS saya saat ini?


21

Saya telah membaca banyak informasi tentang perencanaan persyaratan RAM untuk deduplikasi ZFS. Saya baru saja memutakhirkan RAM server file saya untuk mendukung beberapa dedupe yang sangat terbatas pada ZFS zvols yang tidak dapat saya gunakan snapshot dan klon (karena mereka zvol diformat sebagai sistem file yang berbeda) namun akan berisi banyak data duplikat.

Saya ingin memastikan bahwa RAM baru yang saya tambahkan akan mendukung deduplikasi terbatas yang ingin saya lakukan. Dalam perencanaan, angka-angka saya terlihat bagus tetapi saya ingin memastikan .

Bagaimana saya bisa memberitahu saat ukuran tabel ZFS dedupe (DDTS) pada sistem hidup saya? Saya membaca utas milis ini tetapi saya tidak jelas bagaimana mereka mencapai angka-angka itu. (Saya dapat memposting output zdb tankjika perlu tapi saya sedang mencari jawaban umum yang dapat membantu orang lain)

Jawaban:


17

Anda bisa menggunakan zpool status -D poolnameperintah.

Output akan terlihat mirip dengan:

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

Kolom penting adalah Total blok yang dialokasikan dan Total blok yang direferensikan. Dalam contoh di atas, saya memiliki rasio deduplikasi yang rendah. 40.2G disimpan di disk dalam ruang 37.5G. Atau 2,51 juta blok dalam 2,35 juta blok ruang.

Untuk mendapatkan ukuran sebenarnya dari tabel, lihat:

Entri DDT 2459286, ukuran 481 pada disk, inti 392

2459286 * 392 = 964040112 byte Bagilah dengan 1024 dan 1024 untuk mendapatkan: 919,3MB dalam RAM .


1
permintaan maaf saya karena padat ... dalam contoh yang Anda berikan, bagaimana saya bisa menentukan seberapa besar tabel dedpue , khususnya, berapa banyak RAM / L2ARC yang dikonsumsi?
Josh

1
Lihat pos yang diperbarui.
ewwhite

1
Saya terutama menyukai contoh DDT @ ewwhite, karena itu juga membuat contoh bintang dari rasio yang menghalangi penggunaan dedupe sama sekali. Saya akan mengirim / menerima dataset di kumpulan ini, dari kumpulan data terpotong ke kumpulan data yang tidak terpotong, dan menganggap diri saya beruntung mereka masih cukup kecil untuk membuatnya dapat dikelola. :) Hati-hati dengan asumsi zvol Anda akan dikurangi. Sebagai dedupe level-blok, perbedaan offset tunggal bisa memiringkan semuanya. Jika saya memiliki saran, memindahkan gunung untuk menguji dataset produksi di lab TEST / sebelum / menempatkan ZFS dedupe ke dalam lingkungan produksi.
Nex7

constantin.glez.de/blog/2011/07/zfs-dedupe-or-not-dedupe memiliki beberapa informasi yang baik tentang menghitung kemenangan yang Anda harapkan dari dedup dan biaya yang diharapkan.
jlp

Jawaban ini membutuhkan pembaruan, itu tidak cukup lengkap. Lihat di bawah untuk jawaban yang lebih terperinci
Stilez

5

Setelah membaca utas email asli dan jawaban @ewewite yang mengklarifikasi, saya pikir pertanyaan ini membutuhkan jawaban yang diperbarui, karena jawaban di atas hanya mencakup setengahnya.

Sebagai contoh, mari gunakan output di pool saya. Saya menggunakan perintah zdb -U /data/zfs/zpool.cache -bDDD My_pool. Pada sistem saya, saya memerlukan -Uarg tambahan untuk menemukan file cache ZFS untuk kumpulan, yang disimpan oleh FreeNAS di lokasi yang berbeda dari biasanya; Anda mungkin atau mungkin tidak perlu melakukan itu. Umumnya mencoba zdbtanpa -Uterlebih dahulu, dan jika Anda mendapatkan kesalahan file cache, gunakan find / -name "zpool.cache"atau serupa untuk menemukan file yang dibutuhkan.

Ini adalah hasil aktual saya dan saya telah menafsirkannya di bawah ini:

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

Apa artinya semua itu, dan menghitung ukuran tabel dedup yang sebenarnya:

Output menunjukkan dua sub-tabel, satu untuk blok di mana duplikat ada ( DDT-sha256-zap-duplikat ) dan satu untuk blok di mana tidak ada duplikat ( DDT-sha256-zap-unique ) /. Tabel ketiga di bawah ini memberikan total keseluruhan di kedua hal ini, dan ada ringkasan baris di bawahnya. Melihat hanya pada baris "total" dan ringkasan memberi kita apa yang kita butuhkan:

Ukuran DDT untuk semua blok yang muncul lebih dari satu kali ("DDT-sha256-zap-duplikat") :
771295 entries, size 512 bytes on disk, 165 bytes in RAM ("core")

Ukuran DDT untuk blok yang unik ("DDT-sha256-zap-unique") :
4637966 entries, size 478 bytes on disk, 154 bytes in RAM ("core")

Statistik total DDT untuk semua entri DDT, duplikat + unik ("histogram DDT dikumpulkan di atas semua DDT") :

                    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

Ringkasan :
dedup = 1.24, compress = 1.13, copies = 1.00, dedup * compress / copies = 1.39

Mari kita lakukan beberapa angka.

  • Hitungan blok berfungsi seperti ini: Jumlah entri yang terkait dengan duplikat blok = 771295, jumlah entri yang terkait dengan blok unik = 4637966, total entri dalam tabel DDT harus 771295 + 4637966 = 5409261. Jadi jumlah blok dalam jutaan (biner jutaan) itu!) akan menjadi 5409261 / (1024 ^ 2) = 5,158 juta. Dalam ringkasan kami menemukan ada total 5.16M blok .

  • RAM yang dibutuhkan berfungsi seperti ini: 771295 entri untuk blok duplikat masing-masing menempati 165 byte dalam RAM, dan 4637966 entri untuk blok unik masing-masing menempati 154 byte dalam RAM, sehingga total RAM yang diperlukan untuk tabel dedup sekarang = 841510439 byte = 841510439 / (1024 ^ 2) MBytes = 803 MB = RAM 0,78 GB .

    (Ukuran pada disk yang digunakan dapat dikerjakan dengan cara yang sama, menggunakan angka "ukuran pada disk". Jelas ZFS mencoba menggunakan disk I / O secara efisien dan mengambil keuntungan dari kenyataan bahwa ruang disk yang diambil oleh DDT tidak biasanya masalah. Jadi sepertinya ZFS hanya mengalokasikan sektor 512 byte lengkap untuk setiap entri, atau sesuatu di sepanjang baris itu, bukan hanya 154 atau 165 byte, agar tetap efisien. Ini mungkin tidak termasuk penyisihan beberapa salinan disimpan di disk, yang biasanya ZFS lakukan.)

  • Jumlah total data yang disimpan, dan manfaat dari deduping itu: Dari total statistik DDT, 715 Gbytes ("715G") data disimpan hanya dengan menggunakan 578 GBytes ("578G") dari penyimpanan yang dialokasikan pada disk. Jadi rasio penghematan ruang dedup kami adalah (715 GB data) / (578 GB ruang yang digunakan setelah dikurangi itu) = 1,237 x, itulah yang dikatakan ringkasannya kepada kami ("dedup = 1,24").

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.