ประสิทธิภาพการเขียน dm-crypt (LUKS) ทั่วไปของ Abysmal

ฉันกำลังตรวจสอบปัญหาที่การเข้ารหัสอุปกรณ์บล็อกกำหนดโทษประสิทธิภาพอย่างมากเมื่อเขียนลงไป ชั่วโมงการอ่านทางอินเทอร์เน็ตและการทดลองไม่ได้ทำให้ฉันมีความเข้าใจที่ถูกต้อง

คำถามสั้น ๆ :ทำไมฉันถึงได้ความเร็วการเขียนที่รวดเร็วอย่างสมบูรณ์แบบเมื่อวาง btrfs ลงในอุปกรณ์บล็อก (~ 170MB / s) ในขณะที่ความเร็วในการเขียนลดลง (~ 20MB / s) เมื่อวาง dm-crypt / LUKS ไว้ในระหว่าง ระบบไฟล์และอุปกรณ์บล็อกแม้ว่าระบบจะมีความสามารถในการรองรับปริมาณการเข้ารหัสที่สูงเพียงพอหรือไม่?

สถานการณ์

/home/schlimmchen/randomเป็นไฟล์ 4.0GB ที่เต็มไปด้วยข้อมูลจาก/dev/urandomก่อนหน้านี้

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

การอ่านมันเร็วสุด ๆ :

$ 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

(ครั้งที่สองไฟล์อ่านอย่างชัดเจนจากแคช)

btrfs ที่ไม่ได้เข้ารหัส

อุปกรณ์ถูกจัดรูปแบบโดยตรงกับ btrfs (ไม่มีตารางพาร์ติชันบนอุปกรณ์บล็อก)

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

ความเร็วในการเขียนสูงถึง ~ 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

ความเร็วในการอ่านสูงกว่า 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 บนอุปกรณ์บล็อก

อุปกรณ์ถูกฟอร์แมตด้วย LUKS และอุปกรณ์ผลลัพธ์ถูกจัดรูปแบบด้วย 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

ความเร็วในการอ่านมีเพียงเล็กน้อยเท่านั้น (ทำไมจึงเป็นเช่นนั้น?):

$ 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 ในไฟล์บน btrfs บนอุปกรณ์บล็อก

ความเร็วในการเขียน "skyrockets" มากกว่า 150MB / s เมื่อเขียนลงในไฟล์ที่เข้ารหัส ฉันใส่ btrfs ลงในอุปกรณ์บล็อคจัดสรรไฟล์ 16GB ซึ่งฉันlukfsFormatติดตั้งไว้แล้ว

$ 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

เหตุใดประสิทธิภาพการเขียนจึงเพิ่มขึ้นเช่นนี้ การทำรังของระบบไฟล์และอุปกรณ์บล็อกนี้ช่วยให้เกิดความเร็วในการเขียนสูงได้อย่างไร

ติดตั้ง

ปัญหานี้สามารถทำซ้ำได้ในสองระบบที่ใช้ distro และ kernel เดียวกัน อย่างไรก็ตามฉันยังสังเกตเห็นความเร็วในการเขียนต่ำด้วยเคอร์เนล 3.19.0 บน System2

• อุปกรณ์: Stick USB SanDisk Extreme 64GB USB3.0
• ระบบ 1: Intel NUC 5i5RYH, i5-5250U (Broadwell), 8GB RAM, Samsung 840 EVO 250GB SSD
• ระบบ 2: Lenovo T440p, i5-4300M (Haswell), RAM 16GB, Samsung 850 PRO 256GB SSD
• Distro / Kernel: Debian Jessie, 3.16.7
• cryptsetup: 1.6.6
• /proc/cryptoสำหรับ System1: http://pastebin.com/QUSGMfiS
• cryptsetup benchmarkสำหรับ System1: http://pastebin.com/4RxzPFeT
• btrfs (-tools) คือเวอร์ชัน 3.17
• lsblk -t /dev/sdf: http://pastebin.com/nv49tYWc

ความคิด

• การจัดตำแหน่งไม่ใช่สาเหตุเท่าที่ฉันเห็น แม้ว่าขนาดหน้ากระดาษของแท่งเป็น 16KiB การเริ่มต้นของอัตราการโหลด cryptsetup จะถูกจัดตำแหน่งเป็น 2MiB ต่อไป
• --allow-discards (สำหรับ luksOpen ของ cryptsetup) ไม่ได้ช่วยอย่างที่ฉันคาดไว้
• ในขณะที่ทำการทดลองน้อยลงฉันสังเกตเห็นพฤติกรรมที่คล้ายกันมากกับฮาร์ดไดรฟ์ภายนอกที่เชื่อมต่อผ่านอะแดปเตอร์ USB3.0
• สำหรับฉันดูเหมือนว่าระบบกำลังเขียนบล็อก 64KiB สคริปต์ systemtrapผมพยายามแสดงให้เห็นว่าอย่างน้อย /sys/block/sdf/statสำรองสมมติฐานนี้ขึ้นเนื่องจากมีการรวมการเขียนจำนวนมาก ดังนั้นฉันเดาว่าการเขียนในบล็อกเล็กเกินไปไม่ใช่สาเหตุ
• ไม่มีโชคกับการเปลี่ยนเครื่องมือจัดคิวคิวของอุปกรณ์บล็อกเป็น NOOP
• การใส่รหัสลับในปริมาตร LVM ไม่ได้ช่วยอะไร

คำตอบ (เท่าที่ฉันรู้ตอนนี้): เห็นพ้องด้วย

กล่าวโดยย่อ : การเขียนตามลำดับของฉันไม่ว่าจะเป็นการใช้ddหรือเมื่อคัดลอกไฟล์ (เช่น ... ในการใช้ชีวิตประจำวัน) จะกลายเป็นการเขียนแบบสุ่มหลอก (ไม่ดี) เพราะกระทู้ทั้งสี่ทำงานพร้อมกันในการเขียนข้อมูลที่เข้ารหัสไปยังอุปกรณ์บล็อก การเข้ารหัส (ดี)

การบรรเทา (สำหรับเมล็ดข้าวที่ "เก่ากว่า")

ผลกระทบเชิงลบสามารถลดลงได้โดยการเพิ่มจำนวนของคำร้องขอเข้าคิวในคิวตัวกำหนดตารางเวลา IO ดังนี้:

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

ในกรณีของฉันนี่เกือบสามเท่า (~ 56MB / s) ปริมาณงานสำหรับการทดสอบข้อมูลแบบสุ่ม 4GB ที่อธิบายไว้ในคำถามของฉัน แน่นอนประสิทธิภาพการทำงานยังคงสั้น 100MB / s เมื่อเทียบกับ IO ที่ไม่ได้เข้ารหัส

ตรวจสอบ

multicore blktrace

ฉันตรวจสอบเพิ่มเติมสถานการณ์สมมติของปัญหาที่วาง btrfs ไว้ด้านบนของอุปกรณ์บล็อกที่เข้ารหัส LUKS เพื่อแสดงให้ฉันเห็นว่าคำแนะนำการเขียนที่ออกให้กับอุปกรณ์บล็อคจริงฉันใช้blktraceสิ่งนี้:

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

สิ่งนี้คืออะไร (เท่าที่ฉันสามารถเข้าใจ) ติดตามคำขอ IO /dev/sdcซึ่งเป็นประเภท " เขียน " แล้วแยกวิเคราะห์สิ่งนี้ไปยังผลลัพธ์ที่มนุษย์สามารถอ่านได้ แต่ จำกัด การส่งออกไปยังการกระทำ " D " ซึ่งเป็น (ตามman blkparse) " IO ออกให้กับไดรเวอร์ "

ผลที่ได้คืออะไรเช่นนี้ (ดูผลลัพธ์ประมาณ 5,000 บรรทัดของบันทึกข้อมูลแบบมัลติคอร์ ):

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]

• คอลัมน์ 1: หลัก, รองลงมาของอุปกรณ์บล็อก
• คอลัมน์ 2: CPU ID
• คอลัมน์ 3: หมายเลขลำดับ
• คอลัมน์ 4: การประทับเวลา
• คอลัมน์ 5: ID กระบวนการ
• คอลัมน์ 6: การกระทำ
• คอลัมน์ 7: ข้อมูล RWBS (ประเภท, เซกเตอร์, ความยาว)

นี่เป็นเอาต์พุตที่สร้างขึ้นในขณะที่กำลังddสุ่มข้อมูล 4GB ลงในระบบไฟล์ที่ติดตั้ง เป็นที่ชัดเจนว่ามีกระบวนการที่เกี่ยวข้องอย่างน้อยสองกระบวนการ บันทึกที่เหลือแสดงว่าโปรเซสเซอร์ทั้งสี่กำลังทำงานจริง น่าเศร้าที่คำขอเขียนนั้นไม่ได้สั่งอีกต่อไป ในขณะที่ CPU0 กำลังเขียนที่ใดที่หนึ่งในเซกเตอร์ 38038416th, CPU1 ซึ่งมีกำหนดในภายหลังนั้นกำลังเขียนอยู่ที่เซกเตอร์ 35713872 เลวร้าย.

Singlecore blktrace

ฉันทำการทดลองแบบเดียวกันหลังจากปิดใช้งานมัลติเธรดและปิดการใช้งานคอร์ที่สองของซีพียูของฉัน แน่นอนว่ามีโปรเซสเซอร์เพียงตัวเดียวเท่านั้นที่เกี่ยวข้องกับการเขียนไปยังแท่งควบคุม แต่ที่สำคัญกว่านั้นคำขอเขียนนั้นมีการเรียงลำดับอย่างถูกต้องซึ่งเป็นสาเหตุที่ทำให้ประสิทธิภาพการเขียนแบบเต็มของ ~ 170MB / s ทำได้ในการตั้งค่าเดียวกัน

มีลักษณะที่ประมาณ 5000 เส้นของการส่งออกในบันทึก

การสนทนา

ตอนนี้ฉันรู้สาเหตุและคำค้นหาของ Google ที่เหมาะสมแล้วข้อมูลเกี่ยวกับปัญหานี้กำลังเดือดดาล เมื่อปรากฎว่าฉันไม่ใช่คนแรกที่สังเกตเห็น

• สี่ปีที่ผ่านมาแพทช์นำdm-crypt แบบมัลติเธรดมาสู่เคอร์เนล นั่นเป็นการกระทำที่ตรงกับสิ่งที่ฉันค้นพบ
• สองปีที่ผ่านมามีการพูดถึงการปรับปรุงแพทช์dm-crypt ประสิทธิภาพรวมถึงการเรียงลำดับใหม่ของการร้องขอการเขียน
• หนึ่งปีที่ผ่านมาหัวข้อก็ยังคงกล่าวถึง
• เมื่อเร็ว ๆ นี้แพทช์ที่เปิดใช้งานการเรียงลำดับสำหรับ dm-cryptได้รับการยอมรับกับเคอร์เนล
• มีอีเมลที่น่าสนใจพร้อมการทดสอบประสิทธิภาพ (ซึ่งฉันไม่ได้อ่านมาก) เกี่ยวกับปรากฏการณ์นี้

แก้ไขในเมล็ดปัจจุบัน (> = 4.0.2)

เนื่องจากฉัน (ในภายหลัง) พบว่าเคอร์เนลส่งมอบเป้าหมายที่ชัดเจนในปัญหาที่แน่นอนนี้ฉันต้องการลองเคอร์เนลที่อัปเดต [หลังจากรวบรวมมันเองแล้วก็พบว่ามันมีอยู่แล้วdebian/sid] ปรากฎว่าปัญหาได้รับการแก้ไขแล้ว ฉันไม่ทราบว่าเคอร์เนลรุ่นที่แน่นอนซึ่งการแก้ไขปรากฏขึ้น แต่การกระทำดั้งเดิมจะให้เบาะแสกับทุกคนที่สนใจ

สำหรับบันทึก:

$ 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

ปลายหมวกของ Mikulas Patocka ผู้แต่งความมุ่งมั่น