ทำไม ZFS บน Linux ไม่สามารถใช้ 8x SSD บนอินสแตนซ์ของ AWS i2.8x large ได้อย่างเต็มที่?

ฉันใหม่สำหรับ ZFS อย่างสมบูรณ์ดังนั้นเริ่มต้นด้วยฉันคิดว่าฉันจะทำมาตรฐานง่ายๆเพื่อให้ได้รับความรู้สึกว่ามันทำงานอย่างไร ฉันต้องการผลักดันขีด จำกัด ของประสิทธิภาพดังนั้นฉันจึงเตรียมi2.8xlargeอินสแตนซ์Amazon EC2 (เกือบ $ 7 / ชม. เวลาจริง ๆ แล้วเป็นเงิน!) อินสแตนซ์นี้มี 8 800GB SSD

ฉันfioทำการทดสอบ SSD ด้วยตนเองและได้รับผลลัพธ์ต่อไปนี้ (ตัดแต่ง):

$ sudo fio --name randwrite --ioengine=libaio --iodepth=2 --rw=randwrite --bs=4k --size=400G --numjobs=8 --runtime=300 --group_reporting --direct=1 --filename=/dev/xvdb
[trimmed]
  write: io=67178MB, bw=229299KB/s, iops=57324, runt=300004msec
[trimmed]

57K IOPS สำหรับการเขียนแบบสุ่ม 4K น่านับถือ

ฉันสร้างโวลุ่ม ZFS ที่ครอบคลุมทั้งหมด 8 ตอนแรกฉันมีraidz1vdev หนึ่งตัวที่มี SSD 8 ตัว แต่ฉันอ่านเกี่ยวกับสาเหตุที่ทำให้ประสิทธิภาพลดลงดังนั้นฉันจึงจบลงด้วยmirrorvdev สี่ตัวดังนี้:

$ sudo zpool create testpool mirror xvdb xvdc mirror xvdd xvde mirror xvdf xvdg mirror xvdh xvdi
$ sudo zpool list -v
NAME   SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
testpool  2.91T   284K  2.91T         -     0%     0%  1.00x  ONLINE  -
  mirror   744G   112K   744G         -     0%     0%
    xvdb      -      -      -         -      -      -
    xvdc      -      -      -         -      -      -
  mirror   744G    60K   744G         -     0%     0%
    xvdd      -      -      -         -      -      -
    xvde      -      -      -         -      -      -
  mirror   744G      0   744G         -     0%     0%
    xvdf      -      -      -         -      -      -
    xvdg      -      -      -         -      -      -
  mirror   744G   112K   744G         -     0%     0%
    xvdh      -      -      -         -      -      -
    xvdi      -      -      -         -      -      -

ฉันตั้งค่าการบันทึกเป็น 4K และทำการทดสอบของฉัน:

$ sudo zfs set recordsize=4k testpool
$ sudo fio --name randwrite --ioengine=libaio --iodepth=2 --rw=randwrite --bs=4k --size=400G --numjobs=8 --runtime=300 --group_reporting --filename=/testpool/testfile --fallocate=none
[trimmed]
  write: io=61500MB, bw=209919KB/s, iops=52479, runt=300001msec
    slat (usec): min=13, max=155081, avg=145.24, stdev=901.21
    clat (usec): min=3, max=155089, avg=154.37, stdev=930.54
     lat (usec): min=35, max=155149, avg=300.91, stdev=1333.81
[trimmed]

ฉันได้รับ 52K IOPS เท่านั้นใน ZFS pool นี้ มันแย่กว่า SSD ตัวเดียวเล็กน้อย

ฉันไม่เข้าใจสิ่งที่ฉันทำผิดที่นี่ ฉันกำหนดค่า ZFS ไม่ถูกต้องหรือนี่เป็นการทดสอบประสิทธิภาพของ ZFS ที่ไม่ดีหรือไม่

หมายเหตุฉันใช้อิมเมจ CentOS 7 HVM 64 บิตเป็นทางการ แต่ฉันได้อัพเกรดเป็นเคอร์เนล 4.4.5 elrepo:

$ uname -a
Linux ip-172-31-43-196.ec2.internal 4.4.5-1.el7.elrepo.x86_64 #1 SMP Thu Mar 10 11:45:51 EST 2016 x86_64 x86_64 x86_64 GNU/Linux

ผมติดตั้ง ZFS จาก ZFS ซื้อคืนภาคที่ระบุไว้ที่นี่ ผมมีรุ่น 0.6.5.5 ของzfsแพคเกจ

อัปเดต : ตามคำแนะนำของ @ ewwhite ที่ฉันลองashift=12และashift=13:

$ sudo zpool create testpool mirror xvdb xvdc mirror xvdd xvde mirror xvdf xvdg mirror xvdh xvdi -o ashift=12 -f

และ

$ sudo zpool create testpool mirror xvdb xvdc mirror xvdd xvde mirror xvdf xvdg mirror xvdh xvdi -o ashift=13 -f

ทั้งสองอย่างนี้ต่างกัน จากสิ่งที่ฉันเข้าใจบิต ZFS ล่าสุดนั้นฉลาดพอที่จะระบุ 4K SSD และใช้ค่าเริ่มต้นที่เหมาะสม

ฉันสังเกตเห็นว่าการใช้งาน CPU นั้นรวดเร็วมาก @Tim แนะนำสิ่งนี้ แต่ฉันไม่สนใจ แต่ฉันคิดว่าฉันไม่ได้ดู CPU นานพอที่จะสังเกตเห็น มีบางอย่างเช่น 30 คอร์ของ CPU ในอินสแตนซ์นี้และการใช้งานซีพียูจะเพิ่มขึ้นสูงถึง 80% กระบวนการหิว? z_wr_issมีอินสแตนซ์ของมันมากมาย

ฉันยืนยันว่าการบีบอัดปิดอยู่ดังนั้นจึงไม่ใช่เครื่องมือบีบอัด

ฉันไม่ได้ใช้ Raidz ดังนั้นจึงไม่ควรเป็นการคำนวณความเท่าเทียมกัน

ผมperf topและมันแสดงให้เห็นว่าเวลาส่วนใหญ่ของเคอร์เนลที่ใช้ใน_raw_spin_unlock_irqrestoreในz_wr_int_4และในosq_lockz_wr_iss

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

อัปเดต 2 : ตาม @ whitewhite และข้อเสนอแนะของผู้อื่นว่าเป็นลักษณะเสมือนจริงของสภาพแวดล้อมนี้ที่สร้างความไม่แน่นอนของประสิทธิภาพฉันใช้fioในการเปรียบเทียบการเขียนแบบ 4K ที่กระจายไปทั่ว SSD สี่ตัวในสภาพแวดล้อม SSD แต่ละตัวนั้นให้ ~ 55K IOPS ดังนั้นฉันจึงคาดว่าจะอยู่ที่ประมาณ 240K IOs ในสี่ตัว นั่นคือสิ่งที่ฉันได้รับมากหรือน้อย:

$ sudo fio --name randwrite --ioengine=libaio --iodepth=8 --rw=randwrite --bs=4k --size=398G --numjobs=8 --runtime=300 --group_reporting --filename=/dev/xvdb:/dev/xvdc:/dev/xvdd:/dev/xvde
randwrite: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=8
...
randwrite: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=8
fio-2.1.5
Starting 8 processes
[trimmed]
  write: io=288550MB, bw=984860KB/s, iops=246215, runt=300017msec
    slat (usec): min=1, max=24609, avg=30.27, stdev=566.55
    clat (usec): min=3, max=2443.8K, avg=227.05, stdev=1834.40
     lat (usec): min=27, max=2443.8K, avg=257.62, stdev=1917.54
[trimmed]

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

การตั้งค่านี้อาจปรับได้ไม่ดี มีพารามิเตอร์ที่จำเป็นสำหรับทั้งไฟล์ /etc/modprobe/zfs.conf และค่า ashift เมื่อใช้ SSD

ลอง Ashift = 12 หรือ 13 แล้วทดสอบอีกครั้ง

แก้ไข:

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

แก้ไข:

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

แต่โปรดจำไว้ว่า ZFS มีการตั้งค่าที่ปรับได้จำนวนมากและสิ่งที่คุณได้รับตามค่าเริ่มต้นนั้นไม่ได้อยู่ใกล้กับกรณีการใช้งานของคุณ

ลองทำสิ่งต่อไปนี้ใน/etc/modprobe.d/zfs.confรีบูตของคุณ มันเป็นสิ่งที่ฉันใช้ในพูลข้อมูล SSD ทั้งหมดสำหรับแอปพลิเคชันเซิร์ฟเวอร์ Ashift ของคุณควรเป็น 12 หรือ 13 เกณฑ์มาตรฐานที่มีการบีบอัด = ปิด แต่ใช้การบีบอัด = lz4 ในการผลิต กำหนด atime = off ฉันปล่อยให้บันทึกเป็นค่าเริ่มต้น (128K)

options zfs zfs_vdev_scrub_min_active=48
options zfs zfs_vdev_scrub_max_active=128
options zfs zfs_vdev_sync_write_min_active=64
options zfs zfs_vdev_sync_write_max_active=128
options zfs zfs_vdev_sync_read_min_active=64
options zfs zfs_vdev_sync_read_max_active=128
options zfs zfs_vdev_async_read_min_active=64
options zfs zfs_vdev_async_read_max_active=128
options zfs zfs_top_maxinflight=320
options zfs zfs_txg_timeout=30
options zfs zfs_dirty_data_max_percent=40
options zfs zfs_vdev_scheduler=deadline
options zfs zfs_vdev_async_write_min_active=8
options zfs zfs_vdev_async_write_max_active=64
options zfs zfs_prefetch_disable=1

ดูเหมือนว่าคุณกำลังรอการล็อก mutex เคอร์เนลของ Linux ซึ่งในทางกลับกันอาจกำลังรอบัฟเฟอร์ Xen ring ฉันไม่สามารถมั่นใจได้หากไม่สามารถเข้าถึงเครื่องที่คล้ายกันได้ แต่ฉันไม่สนใจจ่ายอเมซอน $ 7 / ชั่วโมงสำหรับสิทธิ์นั้น

อีกต่อไปเขียนขึ้นอยู่ที่นี่: https://www.reddit.com/r/zfs/comments/4b4r1y/why_is_zfs_on_linux_unable_to_fully_utilize_8x/d1e91wo ; ฉันต้องการที่จะอยู่ในที่เดียวมากกว่าสองแห่ง

ฉันใช้เวลาพอสมควรในการติดตามเรื่องนี้ ความท้าทายเฉพาะของฉัน: เซิร์ฟเวอร์ Postgres และฉันต้องการใช้ ZFS สำหรับปริมาณข้อมูล พื้นฐานคือ XFS

ก่อนอื่นการทดลองของฉันบอกฉันว่าashift=12ผิด หากมีashiftเลขอาถรรพ์ไม่ใช่ 12 ฉันใช้0และฉันได้ผลลัพธ์ที่ดีมาก

ฉันยังได้ทดลองกับตัวเลือก zfs มากมายและสิ่งที่ให้ผลลัพธ์ด้านล่างนี้คือ:

atime=off - ฉันไม่ต้องการเวลาในการเข้าถึง

checksum=off - ฉันกำลังสตริปไม่ใช่มิเรอร์

compression=lz4- ประสิทธิภาพดีขึ้นด้วยการบีบอัด (cpu tradeoff?)

exec=off - ใช้สำหรับข้อมูลไม่ใช่ไฟล์ที่เรียกใช้งานได้

logbias=throughput - อ่าน interwebs ดีกว่าสำหรับ Postgres

recordsize=8k - ขนาดบล็อกเฉพาะ 8k PG

sync=standard- พยายามปิดการซิงค์ ไม่เห็นประโยชน์มากนัก

การทดสอบของฉันด้านล่างแสดงดีกว่าประสิทธิภาพ XFS (โปรดแสดงความคิดเห็นหากคุณเห็นข้อผิดพลาดในการทดสอบของฉัน!)

ด้วยขั้นตอนต่อไปของฉันคือลองใช้ Postgres ในระบบไฟล์ 2 x EBS ZFS

การตั้งค่าเฉพาะของฉัน:

EC2: m4.xlargeอินสแตนซ์

EBS: gp2ปริมาณ250GB

เคอร์เนล: Linux [... ] 3.13.0-105-generic # 152-Ubuntu SMP [... ] x86_64 x86_64 x86_64 GNU / Linux *

ก่อนอื่นฉันต้องการทดสอบประสิทธิภาพ EBS แบบดิบ ด้วยความหลากหลายของfioคำสั่งด้านบนทำให้ฉันมีคาถาด้านล่าง หมายเหตุ: ฉันใช้บล็อกขนาด 8k เพราะนั่นคือสิ่งที่ฉันได้อ่าน PostgreSQL คือ:

ubuntu@ip-172-31-30-233:~$ device=/dev/xvdbd; sudo dd if=/dev/zero of=${device} bs=1M count=100 && sudo fio --name randwrite --ioengine=libaio --iodepth=4 --rw=randwrite --bs=8k --size=400G --numjobs=4 --runtime=60 --group_reporting --fallocate=none --filename=${device}
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.250631 s, 418 MB/s
randwrite: (g=0): rw=randwrite, bs=8K-8K/8K-8K/8K-8K, ioengine=libaio, iodepth=4
...
randwrite: (g=0): rw=randwrite, bs=8K-8K/8K-8K/8K-8K, ioengine=libaio, iodepth=4
fio-2.1.3
Starting 4 processes
Jobs: 4 (f=4): [wwww] [100.0% done] [0KB/13552KB/0KB /s] [0/1694/0 iops] [eta 00m:00s]
randwrite: (groupid=0, jobs=4): err= 0: pid=18109: Tue Feb 14 19:13:53 2017
  write: io=3192.2MB, bw=54184KB/s, iops=6773, runt= 60327msec
    slat (usec): min=2, max=805209, avg=585.73, stdev=6238.19
    clat (usec): min=4, max=805236, avg=1763.29, stdev=10716.41
     lat (usec): min=15, max=805241, avg=2349.30, stdev=12321.43
    clat percentiles (usec):
     |  1.00th=[   15],  5.00th=[   16], 10.00th=[   17], 20.00th=[   19],
     | 30.00th=[   23], 40.00th=[   24], 50.00th=[   25], 60.00th=[   26],
     | 70.00th=[   27], 80.00th=[   29], 90.00th=[   36], 95.00th=[15808],
     | 99.00th=[31872], 99.50th=[35584], 99.90th=[99840], 99.95th=[199680],
     | 99.99th=[399360]
    bw (KB  /s): min=  156, max=1025440, per=26.00%, avg=14088.05, stdev=67584.25
    lat (usec) : 10=0.01%, 20=20.53%, 50=72.20%, 100=0.86%, 250=0.17%
    lat (usec) : 500=0.13%, 750=0.01%, 1000=0.01%
    lat (msec) : 2=0.01%, 4=0.01%, 10=0.59%, 20=2.01%, 50=3.29%
    lat (msec) : 100=0.11%, 250=0.05%, 500=0.02%, 750=0.01%, 1000=0.01%
  cpu          : usr=0.22%, sys=1.34%, ctx=9832, majf=0, minf=114
  IO depths    : 1=0.1%, 2=0.1%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=408595/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
  WRITE: io=3192.2MB, aggrb=54184KB/s, minb=54184KB/s, maxb=54184KB/s, mint=60327msec, maxt=60327msec

Disk stats (read/write):
  xvdbd: ios=170/187241, merge=0/190688, ticks=180/8586692, in_queue=8590296, util=99.51%

ประสิทธิภาพการทำงานของวัตถุดิบสำหรับปริมาณ EBS WRITE: io=3192.2MBคือ

ตอนนี้การทดสอบ XFS ด้วยfioคำสั่งเดียวกัน:

Jobs: 4 (f=4): [wwww] [100.0% done] [0KB/0KB/0KB /s] [0/0/0 iops] [eta 00m:00s]
randwrite: (groupid=0, jobs=4): err= 0: pid=17441: Tue Feb 14 19:10:27 2017
  write: io=3181.9MB, bw=54282KB/s, iops=6785, runt= 60024msec
    slat (usec): min=3, max=21077K, avg=587.19, stdev=76081.88
    clat (usec): min=4, max=21077K, avg=1768.72, stdev=131857.04
     lat (usec): min=23, max=21077K, avg=2356.23, stdev=152444.62
    clat percentiles (usec):
     |  1.00th=[   29],  5.00th=[   40], 10.00th=[   46], 20.00th=[   52],
     | 30.00th=[   56], 40.00th=[   59], 50.00th=[   63], 60.00th=[   69],
     | 70.00th=[   79], 80.00th=[   99], 90.00th=[  137], 95.00th=[  274],
     | 99.00th=[17024], 99.50th=[25472], 99.90th=[70144], 99.95th=[120320],
     | 99.99th=[1564672]
    bw (KB  /s): min=    2, max=239872, per=66.72%, avg=36217.04, stdev=51480.84
    lat (usec) : 10=0.01%, 20=0.03%, 50=15.58%, 100=64.51%, 250=14.55%
    lat (usec) : 500=1.36%, 750=0.33%, 1000=0.25%
    lat (msec) : 2=0.68%, 4=0.67%, 10=0.71%, 20=0.58%, 50=0.59%
    lat (msec) : 100=0.10%, 250=0.02%, 500=0.01%, 750=0.01%, 1000=0.01%
    lat (msec) : 2000=0.01%, >=2000=0.01%
  cpu          : usr=0.43%, sys=4.81%, ctx=269518, majf=0, minf=110
  IO depths    : 1=0.1%, 2=0.1%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=407278/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
  WRITE: io=3181.9MB, aggrb=54282KB/s, minb=54282KB/s, maxb=54282KB/s, mint=60024msec, maxt=60024msec

Disk stats (read/write):
  xvdbd: ios=4/50983, merge=0/319694, ticks=0/2067760, in_queue=2069888, util=26.21%

พื้นฐานของเราคือWRITE: io=3181.9MB; ใกล้เคียงกับความเร็วดิสก์ดิบจริงๆ

ตอนนี้เข้าสู่ ZFS โดยใช้WRITE: io=3181.9MBเป็นข้อมูลอ้างอิง:

ubuntu@ip-172-31-30-233:~$ sudo zpool create testpool xvdbd -f && (for option in atime=off checksum=off compression=lz4 exec=off logbias=throughput recordsize=8k sync=standard; do sudo zfs set $option testpool; done;) && sudo fio --name randwrite --ioengine=libaio --iodepth=4 --rw=randwrite --bs=8k --size=400G --numjobs=4 --runtime=60 --group_reporting --fallocate=none --filename=/testpool/testfile; sudo zpool destroy testpool
randwrite: (g=0): rw=randwrite, bs=8K-8K/8K-8K/8K-8K, ioengine=libaio, iodepth=4
...
randwrite: (g=0): rw=randwrite, bs=8K-8K/8K-8K/8K-8K, ioengine=libaio, iodepth=4
fio-2.1.3
Starting 4 processes
randwrite: Laying out IO file(s) (1 file(s) / 409600MB)
randwrite: Laying out IO file(s) (1 file(s) / 409600MB)
randwrite: Laying out IO file(s) (1 file(s) / 409600MB)
randwrite: Laying out IO file(s) (1 file(s) / 409600MB)
Jobs: 4 (f=4): [wwww] [100.0% done] [0KB/41328KB/0KB /s] [0/5166/0 iops] [eta 00m:00s]
randwrite: (groupid=0, jobs=4): err= 0: pid=18923: Tue Feb 14 19:17:18 2017
  write: io=4191.7MB, bw=71536KB/s, iops=8941, runt= 60001msec
    slat (usec): min=10, max=1399.9K, avg=442.26, stdev=4482.85
    clat (usec): min=2, max=1400.4K, avg=1343.38, stdev=7805.37
     lat (usec): min=56, max=1400.4K, avg=1786.61, stdev=9044.27
    clat percentiles (usec):
     |  1.00th=[   62],  5.00th=[   75], 10.00th=[   87], 20.00th=[  108],
     | 30.00th=[  122], 40.00th=[  167], 50.00th=[  620], 60.00th=[ 1176],
     | 70.00th=[ 1496], 80.00th=[ 2320], 90.00th=[ 2992], 95.00th=[ 4128],
     | 99.00th=[ 6816], 99.50th=[ 9536], 99.90th=[30592], 99.95th=[66048],
     | 99.99th=[185344]
    bw (KB  /s): min= 2332, max=82848, per=25.46%, avg=18211.64, stdev=15010.61
    lat (usec) : 4=0.01%, 50=0.09%, 100=14.60%, 250=26.77%, 500=5.96%
    lat (usec) : 750=5.27%, 1000=4.24%
    lat (msec) : 2=20.96%, 4=16.74%, 10=4.93%, 20=0.30%, 50=0.08%
    lat (msec) : 100=0.04%, 250=0.03%, 500=0.01%, 2000=0.01%
  cpu          : usr=0.61%, sys=9.48%, ctx=177901, majf=0, minf=107
  IO depths    : 1=0.1%, 2=0.1%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=536527/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
  WRITE: io=4191.7MB, aggrb=71535KB/s, minb=71535KB/s, maxb=71535KB/s, mint=60001msec, maxt=60001msec

แจ้งให้ทราบล่วงหน้านี้ทำได้ดีกว่า WRITE: io=4191.7MBXFS ฉันค่อนข้างแน่ใจว่านี่เป็นเพราะการบีบอัด

สำหรับการเตะฉันจะเพิ่มวอลลุ่มที่สอง:

ubuntu@ip-172-31-30-233:~$ sudo zpool create testpool xvdb{c,d} -f && (for option in atime=off checksum=off compression=lz4 exec=off logbias=throughput recordsize=8k sync=standard; do sudo zfs set $option testpool; done;) && sudo fio --name randwrite --ioengine=libaio --iodepth=4 --rw=randwrite --bs=8k --size=400G --numjobs=4 --runtime=60 --group_reporting --fallocate=none --filename=/testpool/testfile; sudo zpool destroy testpool
randwrite: (g=0): rw=randwrite, bs=8K-8K/8K-8K/8K-8K, ioengine=libaio, iodepth=4
...
randwrite: (g=0): rw=randwrite, bs=8K-8K/8K-8K/8K-8K, ioengine=libaio, iodepth=4
fio-2.1.3
Starting 4 processes
randwrite: Laying out IO file(s) (1 file(s) / 409600MB)
randwrite: Laying out IO file(s) (1 file(s) / 409600MB)
randwrite: Laying out IO file(s) (1 file(s) / 409600MB)
randwrite: Laying out IO file(s) (1 file(s) / 409600MB)
Jobs: 4 (f=4): [wwww] [100.0% done] [0KB/71936KB/0KB /s] [0/8992/0 iops] [eta 00m:00s]
randwrite: (groupid=0, jobs=4): err= 0: pid=20901: Tue Feb 14 19:23:30 2017
  write: io=5975.9MB, bw=101983KB/s, iops=12747, runt= 60003msec
    slat (usec): min=10, max=1831.2K, avg=308.61, stdev=4419.95
    clat (usec): min=3, max=1831.6K, avg=942.64, stdev=7696.18
     lat (usec): min=58, max=1831.8K, avg=1252.25, stdev=8896.67
    clat percentiles (usec):
     |  1.00th=[   70],  5.00th=[   92], 10.00th=[  106], 20.00th=[  129],
     | 30.00th=[  386], 40.00th=[  490], 50.00th=[  692], 60.00th=[  796],
     | 70.00th=[  932], 80.00th=[ 1160], 90.00th=[ 1624], 95.00th=[ 2256],
     | 99.00th=[ 5344], 99.50th=[ 8512], 99.90th=[30592], 99.95th=[60672],
     | 99.99th=[117248]
    bw (KB  /s): min=   52, max=112576, per=25.61%, avg=26116.98, stdev=15313.32
    lat (usec) : 4=0.01%, 10=0.01%, 50=0.04%, 100=7.17%, 250=19.04%
    lat (usec) : 500=14.36%, 750=15.36%, 1000=17.41%
    lat (msec) : 2=20.28%, 4=4.82%, 10=1.13%, 20=0.25%, 50=0.08%
    lat (msec) : 100=0.04%, 250=0.02%, 2000=0.01%
  cpu          : usr=1.05%, sys=15.14%, ctx=396649, majf=0, minf=103
  IO depths    : 1=0.1%, 2=0.1%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=764909/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
  WRITE: io=5975.9MB, aggrb=101982KB/s, minb=101982KB/s, maxb=101982KB/s, mint=60003msec, maxt=60003msec

ด้วยโวลุ่มที่สองWRITE: io=5975.9MBดังนั้น ~ 1.8X การเขียน

ไดรฟ์ข้อมูลที่สามให้เราWRITE: io=6667.5MBดังนั้น ~ 2.1X เขียน

WRITE: io=6552.9MBและปริมาณที่สี่จะช่วยให้เรา สำหรับประเภทอินสแตนซ์นี้ดูเหมือนว่าฉันเกือบจะครอบคลุมเครือข่าย EBS ด้วยสองวอลุ่มแน่นอนด้วยสามและก็ไม่ดีขึ้นด้วย 4 (750 * 3 = 2250 IOPS)

* จากวิดีโอนี้ตรวจสอบให้แน่ใจว่าคุณใช้เคอร์เนลลินุกซ์ 3.8+ เพื่อรับความดี EBS ทั้งหมด