Làm thế nào lớn là bảng khấu trừ ZFS của tôi tại thời điểm này?


21

Tôi đã đọc rất nhiều thông tin về việc lập kế hoạch yêu cầu RAM cho việc sao chép ZFS. Tôi vừa nâng cấp RAM máy chủ tệp của mình để hỗ trợ một số khấu trừ rất hạn chế trên các zvols ZFS mà tôi không thể sử dụng ảnh chụp nhanh và nhân bản (vì chúng được định dạng như một hệ thống tệp khác) nhưng sẽ chứa nhiều dữ liệu trùng lặp.

Tôi muốn đảm bảo rằng RAM mới mà tôi đã thêm sẽ hỗ trợ cho việc sao chép hạn chế mà tôi dự định thực hiện. Trong kế hoạch, con số của tôi có vẻ tốt nhưng tôi muốn chắc chắn .

Làm cách nào để biết kích thước hiện tại của các bảng khấu trừ ZFS (DDT) trên hệ thống trực tiếp của tôi? Tôi đọc chủ đề danh sách gửi thư này nhưng tôi không rõ làm thế nào họ nhận được những con số đó. (Tôi có thể đăng kết quả đầu ra zdb tanknếu cần nhưng tôi đang tìm câu trả lời chung có thể giúp người khác)

Câu trả lời:


17

Bạn có thể sử dụng zpool status -D poolnamelệnh.

Đầu ra sẽ trông tương tự như:

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

Các trường quan trọng là Tổng khối được phân bổ và Tổng khối tham chiếu. Trong ví dụ trên, tôi có tỷ lệ trùng lặp thấp. 40.2G được lưu trữ trên đĩa trong 37,5G không gian. Hoặc 2,51 triệu khối trong không gian trị giá 2,35 triệu khối.

Để có được kích thước thực tế của bảng, xem:

Các mục DDT 2459286, kích thước 480 trên đĩa, 392 trong lõi

2459286 * 392 = 964040112 byte Chia cho 1024 và 1024 để nhận: 919.3MB RAM .


1
lời xin lỗi của tôi về sự dày đặc ... trong ví dụ bạn đã cung cấp, làm cách nào tôi có thể xác định bảng khấu trừ lớn đến mức nào , cụ thể là nó tiêu thụ bao nhiêu RAM / L2ARC?
Josh

1
Xem bài cập nhật.
ewwhite

1
Tôi đặc biệt thích ví dụ DDT của @ ewwhite, bởi vì nó cũng tạo ra một ví dụ xuất sắc về tỷ lệ loại trừ việc sử dụng khấu trừ. Tôi đã gửi / recv các bộ dữ liệu trên nhóm này, từ các bộ dữ liệu được khấu trừ đến các bộ dữ liệu không được khấu trừ, và tôi thấy may mắn là chúng vẫn đủ nhỏ để có thể quản lý được. :) Hãy cẩn thận giả sử zvols của bạn sẽ khấu trừ. Là một khoản khấu trừ cấp khối, một sự khác biệt bù trừ duy nhất có thể làm lệch toàn bộ. Nếu tôi có lời khuyên nào, thì nên chuyển núi để kiểm tra tập dữ liệu sản xuất trong phòng thí nghiệm TEST / trước / đưa phần thưởng ZFS vào bất kỳ môi trường sản xuất nào.
Nex7

Constantin.glez.de/blog/2011/07/zfs-dedupe-or-not-dedupe có một số thông tin tốt về việc tính toán chiến thắng dự kiến ​​của bạn từ khoản khấu trừ và chi phí dự kiến ​​của bạn.
jlp

Câu trả lời này cần một bản cập nhật, nó chưa hoàn chỉnh. Xem bên dưới để biết câu trả lời chi tiết hơn
Stilez

5

Sau khi đọc chủ đề email ban đầu và câu trả lời của @ ewwhite đã làm rõ nó, tôi nghĩ rằng câu hỏi này cần một câu trả lời cập nhật, vì câu trả lời ở trên chỉ bao gồm một nửa câu trả lời.

Ví dụ: hãy sử dụng đầu ra trên nhóm của tôi. Tôi đã sử dụng lệnh zdb -U /data/zfs/zpool.cache -bDDD My_pool. Trên hệ thống của tôi, tôi cần thêm -Uđối số để định vị tệp bộ đệm ZFS cho nhóm, mà FreeNAS lưu trữ ở một vị trí khác với bình thường; bạn có thể hoặc không cần phải làm điều đó. Nói chung hãy thử zdbmà không có lỗi -Uđầu tiên và nếu bạn gặp lỗi tệp bộ đệm, sau đó sử dụng find / -name "zpool.cache"hoặc tương tự để xác định vị trí tệp cần thiết.

Đây là đầu ra thực tế của tôi và tôi đã giải thích nó dưới đây:

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

Tất cả có nghĩa là gì, và tính ra kích thước bảng khấu trừ thực tế:

Đầu ra hiển thị hai bảng phụ, một bảng cho các khối tồn tại trùng lặp ( DDT-sha256-zap-trùng lặp ) và một bảng cho các khối không tồn tại trùng lặp ( DDT-sha256-zap-unique ) /. Bảng thứ ba bên dưới chúng đưa ra tổng cộng trên cả hai bảng này và có một hàng tóm tắt bên dưới. Chỉ nhìn vào các hàng "tổng" và tóm tắt cho chúng ta những gì chúng ta cần:

Kích thước DDT cho tất cả các khối xuất hiện nhiều lần ("DDT-sha256-zap-trùng lặp") :
771295 entries, size 512 bytes on disk, 165 bytes in RAM ("core")

Kích thước DDT cho các khối duy nhất ("DDT-sha256-zap-unique") :
4637966 entries, size 478 bytes on disk, 154 bytes in RAM ("core")

Tổng số thống kê DDT cho tất cả các mục DDT, trùng lặp + duy nhất ("biểu đồ DDT được tổng hợp trên tất cả các 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

Tóm tắt :
dedup = 1.24, compress = 1.13, copies = 1.00, dedup * compress / copies = 1.39

Chúng ta hãy làm một số crunching.

  • Số lượng khối hoạt động như thế này: Số lượng mục nhập liên quan đến các khối trùng lặp = 771295, số lượng mục nhập liên quan đến các khối duy nhất = 4637966, tổng số mục trong bảng DDT phải là 771295 + 4637966 = 5409261. Vì vậy, số lượng khối trong hàng triệu (hàng triệu nhị phân nghĩa là!) sẽ là 5409261 / (1024 ^ 2) = 5.158 triệu. Trong bản tóm tắt, chúng tôi thấy có tổng số khối 5,16M .

  • RAM cần thiết hoạt động như thế này: 771295 mục nhập cho các khối trùng lặp, mỗi khối chiếm 165 byte trong RAM và 4637966 mục cho các khối duy nhất mỗi khối chiếm 154 byte trong RAM, do đó, tổng RAM cần cho bảng khấu trừ ngay bây giờ = 841510439 byte = 841510439 / (1024 ^ 2) MByte = 803 MB = 0,78 GB RAM .

    (Kích thước trên đĩa được sử dụng có thể được xử lý theo cùng một cách, sử dụng số liệu "kích thước trên đĩa". Rõ ràng ZFS đang cố gắng sử dụng I / O đĩa hiệu quả và tận dụng thực tế là không gian đĩa được chiếm bởi DDT Thông thường, đây là một vấn đề. Có vẻ như ZFS chỉ đơn giản là phân bổ một khu vực 512 byte hoàn chỉnh cho mỗi mục nhập, hoặc một cái gì đó dọc theo các dòng đó, thay vì chỉ 154 hoặc 165 byte, để giữ cho nó hiệu quả. các bản sao được giữ trên đĩa, mà ZFS thường làm.)

  • Tổng lượng dữ liệu được lưu trữ và lợi ích từ việc khấu trừ dữ liệu đó: Từ tổng số liệu thống kê DDT, 715 Gbytes ("715G") dữ liệu được lưu trữ chỉ bằng 578 GBytes ("578G") lưu trữ được phân bổ trên các đĩa. Vì vậy, tỷ lệ tiết kiệm không gian khấu trừ của chúng tôi là (715 GB dữ liệu) / (578 GB dung lượng được sử dụng sau khi khấu trừ) = 1.237 x, đó là những gì tóm tắt đang nói với chúng tôi ("depup = 1,24").

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.