ZFS pool đọc tuần tự chậm

Tôi có một câu hỏi liên quan về vấn đề này, nhưng nó quá phức tạp và quá lớn, vì vậy tôi quyết định tôi nên chia vấn đề thành NFS và các vấn đề cục bộ. Tôi cũng đã thử hỏi về điều này trong danh sách gửi thư thảo luận zfs mà không thành công lắm.

Sao chép chậm giữa các thư mục NFS / CIFS trên cùng một máy chủ

Đại cương: Cách tôi thiết lập và những gì tôi đang mong đợi

1. Tôi có một hồ bơi ZFS với 4 đĩa. 2TB RED được định cấu hình là 2 gương được sọc (RAID 10). Trên Linux, zfsonlinux. Không có bộ nhớ cache hoặc thiết bị đăng nhập.
2. Dữ liệu được cân bằng trên các gương (quan trọng đối với ZFS)
3. Mỗi đĩa có thể đọc song song (w / dd thô) với tốc độ 147MB / giây, cho thông lượng kết hợp là 588MB / giây.
4. Tôi mong đợi khoảng 115MB / giây ghi, đọc 138 MB / giây và ghi lại 50 MB / giây dữ liệu tuần tự từ mỗi đĩa, dựa trên điểm chuẩn của đĩa RED 4TB tương tự. Tôi mong đợi không dưới 100 MB / giây đọc hoặc ghi, vì bất kỳ đĩa nào cũng có thể làm điều đó trong những ngày này.
5. Tôi nghĩ rằng tôi sẽ thấy việc sử dụng IO 100% trên cả 4 đĩa khi đang đọc hoặc ghi dữ liệu tuần tự. Và rằng các đĩa sẽ được đưa ra hơn 100MB / giây trong khi sử dụng 100%.
6. Tôi nghĩ rằng nhóm sẽ cung cấp cho tôi khoảng 2 lần ghi, ghi lại 2 lần và hiệu suất đọc 4x trên một đĩa - tôi có sai không?
7. MỚI Tôi nghĩ rằng một ext4 zvol trên cùng một nhóm sẽ có cùng tốc độ với ZFS

Những gì tôi thực sự nhận được

Tôi thấy hiệu suất đọc của hồ bơi không cao như tôi mong đợi

điểm chuẩn bonnie ++ trên hồ bơi từ vài ngày trước

Phiên bản 1.97 ------ Đầu ra tuần tự ------ - Đầu vào tương đương- - Cộng đồng-
Đồng thời 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seek--
Kích thước máy K / giây% CP K / giây% CP K / giây% CP K / giây% CP K / giây% CP / giây% CP
igor 63G 99 99 232132 47 118787 27 336 97 257072 22 92.7 6

bonnie ++ trên một ổ RED 4TB duy nhất trên chính nó trong một zpool

Phiên bản 1.97 ------ Đầu ra tuần tự ------ - Đầu vào tương đương- - Cộng đồng-
Đồng thời 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seek--
Kích thước máy K / giây% CP K / giây% CP K / giây% CP K / giây% CP K / giây% CP / giây% CP
igor 63G 101 99 115288 30 49781 14 326 97 138250 13 111.6 8

Theo đó, tốc độ đọc và ghi lại là phù hợp dựa trên kết quả từ một ổ RED 4TB duy nhất (chúng là gấp đôi). Tuy nhiên, tốc độ đọc mà tôi mong đợi sẽ vào khoảng 550MB / giây (gấp 4 lần tốc độ của ổ đĩa 4TB) và ít nhất tôi sẽ hy vọng khoảng 400 MB / giây. Thay vào đó tôi đang thấy khoảng 260MB / giây

bonnie ++ trên hồ bơi từ bây giờ, trong khi thu thập thông tin dưới đây. Không hoàn toàn giống như trước đây, và không có gì thay đổi.

Phiên bản 1.97 ------ Đầu ra tuần tự ------ - Đầu vào tương đương- - Cộng đồng-
Đồng thời 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seek--
Kích thước máy K / giây% CP K / giây% CP K / giây% CP K / giây% CP K / giây% CP / giây% CP
igor 63G 103 99 207518 43 108810 24 342 98 302350 26 256.4 18

zpool iostat trong khi viết. Có vẻ ổn với tôi.

                                                 băng thông hoạt động công suất
phân bổ hồ bơi miễn phí đọc viết đọc viết
-------------------------------------------- ----- - ---- ----- ----- ----- -----
hồ bơi2 1,23T 2,39T 0 1,89K 1,60K 238M
  gương 631G 1.20T 0 979 1.60K 120M
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469 - - 0 1007 1.60K 124M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX - - 0 975 0 120M
  gương 631G 1.20T 0 953 0 117M
    ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536 - - 0 1.01K 0 128M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE - - 0 953 0 117M

zpool iostat trong khi viết lại. Có vẻ ổn với tôi, tôi nghĩ .

                                                 băng thông hoạt động công suất
phân bổ hồ bơi miễn phí đọc viết đọc viết
-------------------------------------------- ----- - ---- ----- ----- ----- -----
hồ bơi2 1.27T 2.35T 1015 923 125M 101M
  gương 651G 1.18T 505 465 62.2M 51.8M
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469 - - 198 438 24.4M 51.7M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX - - 306 384 37.8M 45.1M
  gương 651G 1.18T 510 457 63.2M 49.6M
    ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536 - - 304 371 37.8M 43.3M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE - - 206 423 25,5M 49,6M

Đây là nơi tôi tự hỏi chuyện gì đang xảy ra

zpool iuler trong khi đọc

                                                 băng thông hoạt động công suất
phân bổ hồ bơi miễn phí đọc viết đọc viết
-------------------------------------------- ----- - ---- ----- ----- ----- -----
hồ bơi2 1.27T 2.35T 2.68K 32 339M 141K
  gương 651G 1.18T 1.34K 20 169M 90.0K
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469 - - 748 9 92.5M 96.8K
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX - - 623 10 76.8M 96.8K
  gương 651G 1.18T 1.34K 11 170M 50.8K
    ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536 - - 774 5 95,7M 56,0K
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE - - 599 6 74.0M 56.0K

iter -x trong quá trình đọc tương tự. Lưu ý cách IO% không ở mức 100%.

Thiết bị: rrqm / s wrqm / sr / sw / s rkB / s wkB / s avgrq-sz avgqu-sz đang chờ r_await w_await svctm% produc
sdb 0,60 0,00 661.30 6,00 83652,80 49,20 250,87 2,32 3,47 3,46 4,87 1,20 79,76
sdd 0,80 0,00 735,40 5,30 93273,20 49,20,98,98 2,60 3,51 3,51 4,15 1,20 89,04
sdf 0,50 0,00 656,70 3,80 83196,80 31,20 252,02 2,23 3,38 3,36 6,63 1,17 77,12
sda 0,70 0,00 738,30 3,30 93572,00 31,20 252,44 2,45 3,33 3,31 7,03 1,14 84,24

cài đặt tập dữ liệu zpool và thử nghiệm:

• mất thời gian
• nén bị tắt
• ashift là 0 (autodetect - sự hiểu biết của tôi là điều này ổn)
• zdb nói rằng tất cả các đĩa là ashift = 12
• mô-đun - tùy chọn zfs zvol_threads = 32 zfs_arc_max = 17179869184
• đồng bộ hóa = tiêu chuẩn

Chỉnh sửa - ngày 30 tháng 10 năm 2015

Tôi đã làm thêm một số thử nghiệm

• bộ dữ liệu bonnie ++ w / recordsize = 1M = 226MB write, 392MB đọc tốt hơn nhiều
• tập dữ liệu dd w / record size = 1M = 260MB write, 392MB đọc tốt hơn nhiều
• zvol w / ext4 dd bs = 1M = 128MB ghi, 107MB đọc tại sao lại chậm như vậy?
• tập dữ liệu 2 processess song song = 227MB write, 396MB read
• dd direct io không khác nhau về tập dữ liệu và trên zvol

Tôi hạnh phúc hơn nhiều với hiệu suất với kích thước bản ghi tăng lên. Hầu như tất cả các tệp trên nhóm là hơn 1MB. Vì vậy, tôi sẽ để nó như thế. Các đĩa vẫn không được sử dụng 100%, điều này khiến tôi tự hỏi liệu nó có thể nhanh hơn nhiều không. Và bây giờ tôi đang tự hỏi tại sao hiệu suất zvol lại tệ đến vậy, vì đó là thứ tôi (nhẹ) sử dụng.

Tôi vui mừng cung cấp bất kỳ thông tin được yêu cầu trong các ý kiến ​​/ câu trả lời. Ngoài ra còn có rất nhiều thông tin được đăng trong câu hỏi khác của tôi: Sao chép chậm giữa các thư mục NFS / CIFS trên cùng một máy chủ

Tôi hoàn toàn nhận thức được rằng tôi có thể không hiểu điều gì đó và đây có thể không phải là vấn đề. Cảm ơn trước.

Để làm rõ, câu hỏi là: Tại sao nhóm ZFS không nhanh như tôi mong đợi? Và có lẽ còn điều gì sai?

Tôi đã xoay sở để có được tốc độ rất gần với con số mà tôi mong đợi.

Tôi đã tìm kiếm 400MB / giây và quản lý 392MB / giây . Vì vậy, tôi nói rằng đó là vấn đề được giải quyết. Với sự bổ sung sau này của một thiết bị bộ nhớ cache, tôi đã quản lý được đọc 45 MB / giây (tôi tin vào bộ nhớ cache).

1. Điều này lúc đầu đã đạt được chỉ bằng cách tăng recordsizegiá trị bộ dữ liệu ZFS lên1M

zfs set recordsize=1M pool2/test

Tôi tin rằng sự thay đổi này chỉ dẫn đến hoạt động của đĩa ít hơn, do đó đọc và ghi đồng bộ lớn hiệu quả hơn. Chính xác những gì tôi đã yêu cầu.

Kết quả sau khi thay đổi

• bonnie ++ = 226 MB ghi, đọc 392 MB
• dd = 260MB ghi, đọc 392 MB
• 2 tiến trình song song = 227MB ghi, đọc 396 MB

2. Tôi đã quản lý tốt hơn nữa khi tôi thêm một thiết bị bộ nhớ cache (SSD 120 GB). Bài viết chậm hơn một chút, tôi không chắc tại sao.

Version  1.97       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
igor            63G           208325  48 129343  28           458513  35 326.8  16

Thủ thuật với thiết bị bộ đệm là đặt l2arc_noprefetch=0trong /etc/modprobe.d/zfs.conf . Nó cho phép ZFS lưu trữ dữ liệu trực tuyến / tuần tự. Chỉ làm điều này nếu thiết bị bộ nhớ cache của bạn nhanh hơn mảng của bạn, như của tôi.

Sau khi hưởng lợi từ thay đổi recordsize trên tập dữ liệu của tôi, tôi nghĩ rằng nó có thể là một cách tương tự để đối phó với hiệu suất zvol kém.

Tôi đã bắt gặp những người nghiêm khắc đề cập rằng họ đã đạt được hiệu suất tốt khi sử dụng a volblocksize=64k, vì vậy tôi đã thử nó. Không may mắn.

zfs create -b 64k -V 120G pool/volume

Nhưng sau đó tôi đọc rằng ext4 (hệ thống tập tin mà tôi đang thử nghiệm) hỗ trợ các tùy chọn cho RAID như stridevà stripe-width, điều mà tôi chưa từng sử dụng trước đây. Vì vậy, tôi đã sử dụng trang web này để tính toán các cài đặt cần thiết: https://busybox.net/~aldot/mkfs_stride.html và định dạng lại zvol.

mkfs.ext3 -b 4096 -E stride=16,stripe-width=32 /dev/zvol/pool/volume

Tôi chạy bonnie++để làm một điểm chuẩn đơn giản và kết quả là tuyệt vời. Thật không may, tôi không có kết quả với tôi, nhưng chúng ít nhất nhanh hơn 5-6 lần cho việc viết khi tôi nhớ lại. Tôi sẽ cập nhật câu trả lời này một lần nữa nếu tôi điểm chuẩn lại.

Kết quả của bạn là hoàn toàn hợp lý, trong khi kỳ vọng của bạn thì không: bạn nói quá về cải thiện hiệu suất đọc được cung cấp bởi RAID1 (và, bằng phần mở rộng, bởi RAID10). Vấn đề là phản chiếu 2 chiều cho tốc độ đọc / IOP của đĩa đơn nhiều nhất gấp 2 lần, nhưng hiệu suất trong thế giới thực có thể ở bất kỳ đâu trong khoảng 1x-2x.

Hãy làm rõ với một ví dụ. Hãy tưởng tượng có một hệ thống với gương 2 chiều, với mỗi đĩa có khả năng 100 MB / s (tuần tự) và 200 IOPS. Với độ sâu hàng đợi là 1 (tối đa một yêu cầu duy nhất, nổi bật), mảng này sẽ không có lợi thế so với một đĩa đơn: RAID1 chia tách các yêu cầu IO trên hàng đợi của hai đĩa, nhưng ít nhất nó không phân chia một yêu cầu trên hai đĩa (ít nhất là, bất kỳ thực hiện nào tôi thấy hành xử theo cách này). Mặt khác, nếu hàng đợi IO của bạn lớn hơn (ví dụ: bạn có 4/8 yêu cầu chưa xử lý), tổng thông lượng đĩa sẽ cao hơn đáng kể so với đĩa đơn.

Một điểm tương tự có thể được thực hiện cho RAID0, nhưng trong trường hợp này, yếu tố quyết định các cải tiến trung bình là chức năng không chỉ kích thước hàng đợi, mà cả kích thước yêu cầu IO : nếu kích thước IO trung bình của bạn thấp hơn kích thước khối, thì nó sẽ không bị sọc trên hai (hoặc nhiều) đĩa, nhưng nó sẽ được phục vụ bởi một đĩa duy nhất. Kết quả của bạn với bản ghi Bonnie ++ tăng cho thấy hành vi chính xác này: tước đi lợi ích rất lớn từ kích thước IO lớn hơn.

Bây giờ nên rõ ràng rằng việc kết hợp hai cấp độ RAID trong một mảng RAID10 sẽ không dẫn đến việc mở rộng hiệu năng tuyến tính, nhưng nó đặt giới hạn trên cho nó. Tôi khá chắc chắn rằng nếu bạn chạy nhiều phiên bản dd / bonnie ++ (hoặc sử dụng fiođể trực tiếp thao tác hàng đợi IO), bạn sẽ có kết quả phù hợp hơn với mong đợi ban đầu của mình, đơn giản vì bạn sẽ đánh thuế mảng IO của mình theo cách hoàn chỉnh hơn ( nhiều yêu cầu IO liên tiếp / ngẫu nhiên), thay vì tải các yêu cầu IO đơn, tuần tự một mình.