Hiệu suất ghi dm-crypt (LUKS) của Abysmal


21

Tôi đang điều tra một vấn đề trong đó mã hóa một thiết bị khối áp dụng một hình phạt hiệu năng rất lớn khi viết cho nó. Hàng giờ đọc và thử nghiệm trên Internet không cung cấp cho tôi một sự hiểu biết đúng đắn, chứ đừng nói đến một giải pháp.

Câu hỏi ngắn gọn: Tại sao tôi có tốc độ ghi hoàn toàn nhanh khi đặt btrfs vào thiết bị khối (~ 170MB / s), trong khi tốc độ ghi giảm mạnh (~ 20MB / s) khi đặt dm-crypt / LUKS vào giữa hệ thống tập tin và thiết bị khối, mặc dù hệ thống có nhiều khả năng duy trì thông lượng mã hóa đủ cao?

Kịch bản

/home/schlimmchen/randomlà một tệp 4.0GB chứa đầy dữ liệu từ /dev/urandomtrước đó.

dd if=/dev/urandom of=/home/schlimmchen/Documents/random bs=1M count=4096

Đọc nó là siêu nhanh:

$ dd if=/home/schlimmchen/Documents/random of=/dev/null bs=1M
4265841146 bytes (4.3 GB) copied, 6.58036 s, 648 MB/s
$ dd if=/home/schlimmchen/Documents/random of=/dev/null bs=1M
4265841146 bytes (4.3 GB) copied, 0.786102 s, 5.4 GB/s

(lần thứ hai, tập tin rõ ràng đã được đọc từ bộ đệm).

Btrfs không được mã hóa

Thiết bị được định dạng trực tiếp bằng btrfs (không có bảng phân vùng trên thiết bị khối).

$ sudo mkfs.btrfs /dev/sdf
$ sudo mount /dev/sdf /mnt
$ sudo chmod 777 /mnt

Tốc độ ghi lên tới ~ 170MB / s:

$ dd if=/home/schlimmchen/Documents/random of=/mnt/dd-test1 bs=1M conv=fsync
4265841146 bytes (4.3 GB) copied, 27.1564 s, 157 MB/s
$ dd if=/home/schlimmchen/Documents/random of=/mnt/dd-test2 bs=1M conv=fsync
4265841146 bytes (4.3 GB) copied, 25.1882 s, 169 MB/s
$ dd if=/home/schlimmchen/Documents/random of=/mnt/dd-test3 bs=1M conv=fsync
4265841146 bytes (4.3 GB) copied, 29.8419 s, 143 MB/s

Tốc độ đọc tốt hơn 200MB / s.

$ dd if=/mnt/dd-test1 of=/dev/null bs=1M
4265841146 bytes (4.3 GB) copied, 19.8265 s, 215 MB/s
$ dd if=/mnt/dd-test2 of=/dev/null bs=1M
4265841146 bytes (4.3 GB) copied, 19.9821 s, 213 MB/s
$ dd if=/mnt/dd-test3 of=/dev/null bs=1M
4265841146 bytes (4.3 GB) copied, 19.8561 s, 215 MB/s

Btrfs được mã hóa trên thiết bị khối

Thiết bị được định dạng bằng LUKS và thiết bị kết quả được định dạng bằng btrfs:

$ sudo cryptsetup luksFormat /dev/sdf
$ sudo cryptsetup luksOpen /dev/sdf crypt
$ sudo mkfs.btrfs /dev/mapper/crypt
$ sudo mount /dev/mapper/crypt /mnt
$ sudo chmod 777 /mnt
$ dd if=/home/schlimmchen/Documents/random of=/mnt/dd-test1 bs=1M conv=fsync
4265841146 bytes (4.3 GB) copied, 210.42 s, 20.3 MB/s
$ dd if=/home/schlimmchen/Documents/random of=/mnt/dd-test2 bs=1M 
4265841146 bytes (4.3 GB) copied, 207.402 s, 20.6 MB/s

Tốc độ đọc chỉ bị ảnh hưởng nhẹ (tại sao lại không?):

$ dd if=/mnt/dd-test1 of=/dev/null bs=1M
4265841146 bytes (4.3 GB) copied, 22.2002 s, 192 MB/s
$ dd if=/mnt/dd-test2 of=/dev/null bs=1M
4265841146 bytes (4.3 GB) copied, 22.0794 s, 193 MB/s

luksDump: http://pastebin.com/i9VYRR0p

Btrfs được mã hóa trong tệp trên btrfs trên thiết bị khối

Tốc độ ghi "skyrockets" tới hơn 150MB / s khi ghi vào tệp được mã hóa. Tôi đặt một btrfs vào thiết bị khối, cấp phát một tệp 16 GB, mà tôi lukfsFormatđã chỉnh sửa và gắn kết.

$ sudo mkfs.btrfs /dev/sdf -f
$ sudo mount /dev/sdf /mnt
$ sudo chmod 777 /mnt
$ dd if=/dev/zero of=/mnt/crypted-file bs=1M count=16384 conv=fsync
17179869184 bytes (17 GB) copied, 100.534 s, 171 MB/s
$ sudo cryptsetup luksFormat /mnt/crypted-file
$ sudo cryptsetup luksOpen /mnt/crypted-file crypt
$ sudo mkfs.btrfs /dev/mapper/crypt
$ sudo mount /dev/mapper/crypt /tmp/nested/
$ dd if=/home/schlimmchen/Documents/random of=/tmp/nested/dd-test1 bs=1M conv=fsync
4265841146 bytes (4.3 GB) copied, 26.4524 s, 161 MB/s
$ dd if=/home/schlimmchen/Documents/random of=/tmp/nested/dd-test2 bs=1M conv=fsync
4265841146 bytes (4.3 GB) copied, 27.5601 s, 155 MB/s

Tại sao hiệu suất ghi tăng như thế này? Việc lồng các hệ thống tập tin và thiết bị khối đặc biệt này đạt được điều gì để hỗ trợ tốc độ ghi cao?

Thiết lập

Vấn đề có thể tái tạo trên hai hệ thống chạy cùng một bản phân phối và kernel. Tuy nhiên, tôi cũng quan sát tốc độ ghi thấp với kernel 3.19.0 trên System2.

  • Thiết bị: Thanh USB USB3.0 của SanDisk Extreme 64GB
  • Hệ thống1: Intel NUC 5i5RYH, i5-5250U (Broadwell), RAM 8GB, SSD Samsung 840 EVO 250GB
  • Hệ thống2: Lenovo T440p, i5-4300M (Haswell), RAM 16 GB, SSD Samsung 850 PRO 256GB
  • Phân phối / Hạt nhân: Debian Jessie, 3.16.7
  • cryptsetup: 1.6.6
  • /proc/cryptocho Hệ thống1: http://pastebin.com/QUSGMfiS
  • cryptsetup benchmarkcho Hệ thống1: http://pastebin.com/4RxzPFeT
  • btrfs (-tools) là phiên bản 3.17
  • lsblk -t /dev/sdf: http://pastebin.com/nv49tYWc

Suy nghĩ

  • Căn chỉnh không phải là nguyên nhân xa như tôi có thể thấy. Ngay cả khi kích thước trang của thanh là 16KiB, thì bắt đầu tải trọng của cryptsetup vẫn được căn chỉnh thành 2MiB.
  • --allow-discards (đối với luksOpen của cryptsetup) không giúp được gì, như tôi đã mong đợi.
  • Trong khi thực hiện ít thử nghiệm hơn với nó, tôi đã quan sát hành vi rất giống với ổ cứng ngoài, được kết nối qua bộ chuyển đổi USB3.0.
  • Dường như với tôi rằng hệ thống đang viết các khối 64KiB. Một kịch bản systemtrap tôi đã cố gắng chỉ ra rằng ít nhất. /sys/block/sdf/statủng hộ giả thuyết này vì rất nhiều bài viết được hợp nhất. Vì vậy, tôi đoán là viết trong các khối quá nhỏ không phải là nguyên nhân.
  • Không có may mắn với việc thay đổi lịch trình hàng đợi thiết bị khối thành NOOP.
  • Đặt mật mã vào một khối LVM không giúp được gì.

Xóa bộ nhớ cache của đĩa trước mỗi lần kiểm tra sẽ loại bỏ nó như một lý do có thể về tốc độ (hiện tại âm thanh 648 MB / giây không thể thực hiện được, bên ngoài ram)
Xen2050

Câu trả lời:


18

Câu trả lời (như tôi biết bây giờ): đồng thời .

Tóm lại : Viết tuần tự của tôi , bằng cách sử dụng ddhoặc khi sao chép một tệp (như ... trong sử dụng hàng ngày), trở thành ghi giả ngẫu nhiên (xấu) vì bốn luồng đang hoạt động đồng thời trên việc ghi dữ liệu được mã hóa vào thiết bị khối sau khi đồng thời mã hóa (tốt).

Giảm thiểu (cho hạt nhân "cũ")

Hiệu ứng tiêu cực có thể được giảm thiểu bằng cách tăng số lượng yêu cầu được xếp hàng trong hàng đợi lập lịch IO như thế này:

echo 4096 | sudo tee /sys/block/sdc/queue/nr_requests

Trong trường hợp của tôi, con số này gần gấp ba (~ 56MB / s) thông lượng cho thử nghiệm dữ liệu ngẫu nhiên 4GB được giải thích trong câu hỏi của tôi. Tất nhiên, hiệu suất vẫn giảm 100MB / s so với IO không được mã hóa.

Cuộc điều tra

Đa sắc blktrace

Tôi đã nghiên cứu thêm về kịch bản có vấn đề trong đó một btrfs được đặt trên đỉnh của một thiết bị khối mã hóa LUKS. Để chỉ cho tôi những hướng dẫn viết nào được cấp cho thiết bị khối thực tế, tôi đã sử dụng blktracenhư thế này:

sudo blktrace -a write -d /dev/sdc -o - | blkparse -b 1 -i - | grep -w D

Điều này làm là (theo như tôi có thể hiểu) theo dõi yêu cầu IO /dev/sdcthuộc loại " ghi ", sau đó phân tích điều này thành đầu ra có thể đọc được của con người nhưng tiếp tục hạn chế đầu ra thành hành động " D ", theo (theo man blkparse) " IO cấp cho lái xe ".

Kết quả là như thế này (xem khoảng 5000 dòng đầu ra của nhật ký đa lõi ):

8,32   0    32732   127.148240056     3  D   W 38036976 + 240 [ksoftirqd/0]
8,32   0    32734   127.149958221     3  D   W 38038176 + 240 [ksoftirqd/0]
8,32   0    32736   127.160257521     3  D   W 38038416 + 240 [ksoftirqd/0]
8,32   1    30264   127.186905632    13  D   W 35712032 + 240 [ksoftirqd/1]
8,32   1    30266   127.196561599    13  D   W 35712272 + 240 [ksoftirqd/1]
8,32   1    30268   127.209431760    13  D   W 35713872 + 240 [ksoftirqd/1]
  • Cột 1: chính, phụ của thiết bị khối
  • Cột 2: ID CPU
  • Cột 3: số thứ tự
  • Cột 4: dấu thời gian
  • Cột 5: ID tiến trình
  • Cột 6: hành động
  • Cột 7: Dữ liệu RWBS (loại, ngành, chiều dài)

Đây là một đoạn trích của đầu ra được tạo ra trong khi dd'nhập dữ liệu ngẫu nhiên 4GB vào hệ thống tệp được gắn. Rõ ràng là có ít nhất hai quá trình có liên quan. Nhật ký còn lại cho thấy rằng cả bốn bộ xử lý đang thực sự làm việc với nó. Đáng buồn thay, các yêu cầu viết không được đặt hàng nữa. Trong khi CPU0 đang viết ở đâu đó xung quanh khu vực thứ 38038416, CPU1, được lên lịch sau đó, đang viết ở đâu đó quanh khu vực 35713872. Điều đó thật xấu.

Đơn ca blktrace

Tôi đã làm thí nghiệm tương tự sau khi vô hiệu hóa đa luồng và vô hiệu hóa lõi thứ hai của CPU. Tất nhiên, chỉ có một bộ xử lý có liên quan đến việc ghi vào thanh. Nhưng quan trọng hơn, yêu cầu ghi là tuần tự đúng, đó là lý do tại sao hiệu suất ghi đầy đủ ~ 170MB / s đạt được trong cùng một thiết lập.

Hãy xem khoảng 5000 dòng đầu ra trong nhật ký singlecore .

Thảo luận

Bây giờ tôi đã biết nguyên nhân và các thuật ngữ tìm kiếm google thích hợp, thông tin về vấn đề này đang nổi lên trên bề mặt. Hóa ra, tôi không phải là người đầu tiên nhận thấy.

Đã sửa lỗi trong các nhân hiện tại (> = 4.0.2)

Bởi vì tôi (sau này) đã tìm thấy kernel kernel rõ ràng nhắm vào vấn đề chính xác này, tôi muốn thử một kernel đã cập nhật. [Sau khi tự biên dịch nó và sau đó phát hiện ra nó đã xảy ra debian/sid] Hóa ra vấn đề thực sự đã được khắc phục. Tôi không biết bản phát hành kernel chính xác trong đó bản sửa lỗi xuất hiện, nhưng bản cam kết ban đầu sẽ đưa ra manh mối cho bất kỳ ai quan tâm.

Đối với hồ sơ:

$ uname -a
Linux t440p 4.0.0-1-amd64 #1 SMP Debian 4.0.2-1 (2015-05-11) x86_64 GNU/Linux
$ dd if=/home/schlimmchen/Documents/random of=/mnt/dd-test bs=1M conv=fsync
4294967296 bytes (4.3 GB) copied, 29.7559 s, 144 MB/s

Một chiếc mũ cho Mik Formula Patocka, người là tác giả của cam kết.


1
Tôi đang sử dụng btrfs trên luks với kernel 4.12.12 và sự chậm lại vẫn còn đó!
brauliobo

Tại sao bạn nói chậm lại vẫn còn đó? bạn đang sử dụng tài liệu tham khảo nào để không bị chậm lại? thiết lập của bạn là gì? Bạn đã kiểm tra hiệu suất ổ đĩa khi chỉ loại bỏ LUKS?
schlimmchen

xác nhận nó vẫn liên quan đến LUKS unix.stackexchange.com/a/393521/39985
brauliobo

1
Bây giờ tôi hiểu lý do tại sao bạn sẽ viết về việc vẫn trải qua một "sự chậm lại". Tuy nhiên, vấn đề của bạn chỉ liên quan đến vấn đề này, nó chắc chắn không phải là vấn đề tương tự (tụt hậu so với hiệu suất thấp). Tôi cũng có kinh nghiệm về những điều khó chịu này, vì vậy tôi rất biết ơn vì bạn đã chỉ ra vấn đề của bạn ở đây! Không sử dụng LUKS không phải là một lựa chọn, nhưng thật tốt khi biết rằng nó dường như có liên quan đến nguyên nhân.
schlimmchen
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.