Tại sao ZFS trên Linux không thể sử dụng đầy đủ SSD 8 GB trên phiên bản AWS i2.8xlarge?

Tôi hoàn toàn mới với ZFS, vì vậy, khi bắt đầu tôi nghĩ tôi đã thực hiện một số điểm chuẩn đơn giản trên đó để cảm nhận về cách hoạt động của nó. Tôi muốn đẩy các giới hạn về hiệu suất của nó vì vậy tôi đã cung cấp một phiên bản Amazon EC2 i2.8xlarge(gần $ 7 / giờ, thời gian thực sự là tiền!). Trường hợp này có 8 ổ SSD 800 GB.

Tôi đã fiotự mình kiểm tra ổ SSD và nhận được kết quả đầu ra sau đây (được cắt bớt):

$ 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]

IOK 57K cho ghi ngẫu nhiên 4K. Đáng kính trọng.

Sau đó, tôi đã tạo ra một khối lượng ZFS kéo dài tất cả 8. Lúc đầu, tôi có một raidz1vdev với tất cả 8 ổ SSD trong đó, nhưng tôi đã đọc về lý do điều này không tốt cho hiệu suất, vì vậy tôi đã kết thúc với bốn mirrorvdev, như vậy:

$ 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      -      -      -         -      -      -

Tôi đặt recordsize thành 4K và chạy thử nghiệm của mình:

$ 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]

Tôi chỉ nhận được 52K IOPS trên nhóm ZFS này. Điều đó thực sự tồi tệ hơn một ổ SSD.

Tôi không hiểu những gì tôi đang làm sai ở đây. Tôi đã cấu hình ZFS không chính xác, hay đây là một thử nghiệm kém về hiệu suất ZFS?

Lưu ý Tôi đang sử dụng hình ảnh CentOS 7 HVM 64 bit chính thức, mặc dù tôi đã nâng cấp lên kernel 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

Tôi đã cài đặt ZFS từ repo zfs được liệt kê ở đây . Tôi có phiên bản 0.6.5.5 của zfsgói.

CẬP NHẬT : Đề xuất của Per @ ewwhite tôi đã thử ashift=12và ashift=13:

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

và

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

Không ai trong số này làm cho bất kỳ sự khác biệt. Từ những gì tôi hiểu, các bit ZFS mới nhất đủ thông minh để xác định SSD 4K và sử dụng các giá trị mặc định hợp lý.

Tôi đã thông báo tuy nhiên việc sử dụng CPU là tăng vọt. @Tim đề xuất điều này nhưng tôi đã loại bỏ nó tuy nhiên tôi nghĩ rằng tôi đã không xem CPU đủ lâu để nhận thấy. Có một cái gì đó giống như 30 lõi CPU trong trường hợp này và việc sử dụng CPU đang tăng lên đến 80%. Quá trình đói? z_wr_iss, rất nhiều trường hợp của nó.

Tôi xác nhận nén là tắt, vì vậy nó không phải là công cụ nén.

Tôi không sử dụng raidz, vì vậy nó không nên là tính toán tương đương.

Tôi đã làm một perf topvà nó cho thấy phần lớn thời gian kernel chi tiêu trong _raw_spin_unlock_irqrestorenăm z_wr_int_4và osq_locktrong z_wr_iss.

Bây giờ tôi tin rằng có một thành phần CPU cho nút cổ chai hiệu năng này, mặc dù tôi không thể tìm ra nó có thể là gì.

CẬP NHẬT 2 : Đề xuất của Per @ewwhite và những người khác rằng đó là bản chất ảo hóa của môi trường này tạo ra sự không chắc chắn về hiệu suất, tôi đã sử dụng fiođể ghi điểm 4K ngẫu nhiên trải rộng trên bốn ổ SSD trong môi trường. Mỗi ổ SSD tự cung cấp ~ 55K IOPS, vì vậy tôi mong đợi ở đâu đó khoảng 240K IO trên bốn trong số chúng. Đó là ít nhiều những gì tôi nhận được:

$ 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]

Điều này cho thấy rõ môi trường, được ảo hóa mặc dù có thể, có thể duy trì IOPS cao hơn nhiều so với những gì tôi đang thấy. Một cái gì đó về cách ZFS được thực hiện là giữ cho nó không đạt tốc độ tối đa. Tôi chỉ không thể hiểu đó là gì.

Thiết lập này có thể không được điều chỉnh tốt. Có các tham số cần thiết cho cả tệp /etc/modprobe/zfs.conf và giá trị ashift khi sử dụng SSD

Hãy thử ashift = 12 hoặc 13 và kiểm tra lại.

Biên tập:

Đây vẫn là một giải pháp ảo hóa, vì vậy chúng tôi không biết quá nhiều về phần cứng cơ bản hoặc cách mọi thứ được kết nối với nhau. Tôi không biết rằng bạn sẽ có hiệu suất tốt hơn từ giải pháp này.

Biên tập:

Tôi đoán tôi không thấy điểm cố gắng tối ưu hóa một thể hiện của đám mây theo cách này. Bởi vì nếu hiệu suất cao nhất là mục tiêu, bạn sẽ sử dụng phần cứng, phải không?

Nhưng hãy nhớ rằng ZFS có rất nhiều cài đặt có thể điều chỉnh và mặc định những gì bạn nhận được không phải là bất kỳ nơi nào gần với trường hợp sử dụng của bạn.

Hãy thử những điều sau đây trong /etc/modprobe.d/zfs.confvà khởi động lại. Đó là những gì tôi sử dụng trong nhóm dữ liệu toàn SSD của mình cho các máy chủ ứng dụng. Ashift của bạn nên là 12 hoặc 13. Điểm chuẩn với nén = tắt, nhưng sử dụng nén = lz4 trong sản xuất. Đặt atime = tắt. Tôi sẽ để hồ sơ theo mặc định (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

Có vẻ như bạn đang chờ đợi khóa mutex kernel Linux mà đến lượt nó có thể đang chờ trên bộ đệm vòng Xen. Tôi không thể chắc chắn điều này mà không truy cập vào một máy tương tự, nhưng tôi không quan tâm đến việc trả cho Amazon 7 đô la / giờ cho đặc quyền đó.

Bài viết dài hơn có tại đây: https://www.reddit.com/r/zfs/comments/4b4r1y/why_is_zfs_on_linux_unable_to_fully_utilize_8x/d1e91wo ; Tôi thích ở một nơi hơn hai.

Tôi đã dành một khoảng thời gian kha khá để cố gắng theo dõi điều này. Thách thức cụ thể của tôi: một máy chủ Postgres và tôi muốn sử dụng ZFS cho khối lượng dữ liệu của nó. Đường cơ sở là XFS.

Đầu tiên và quan trọng nhất, các thử nghiệm của tôi cho tôi biết đó ashift=12là sai. Nếu có một số ma thuật ashiftthì không phải 12. Tôi đang sử dụng 0và tôi đang nhận được kết quả rất tốt.

Tôi cũng đã thử nghiệm với một loạt các tùy chọn zfs và những tùy chọn cho tôi kết quả bên dưới là:

atime=off - Tôi không cần thời gian truy cập

checksum=off - Tôi đang lột đồ, không phản chiếu

compression=lz4- Hiệu suất tốt hơn với nén (trao đổi cpu?)

exec=off - Đây là cho dữ liệu, không phải thực thi

logbias=throughput - Đọc trên các interwebs này là tốt hơn cho Postgres

recordsize=8k - Kích thước khối 8k PG cụ thể

sync=standard- đã cố gắng tắt đồng bộ hóa; không thấy nhiều lợi ích

Các thử nghiệm của tôi bên dưới hiển thị tốt hơn hiệu suất XFS (vui lòng nhận xét nếu bạn thấy lỗi trong các thử nghiệm của tôi!).

Với bước này, bước tiếp theo của tôi là thử Postgres chạy trên hệ thống tệp 2 x EBS ZFS.

Thiết lập cụ thể của tôi:

EC2: m4.xlargeví dụ

EBS: dung gp2lượng 250GB

kernel: Linux [...] 3.13.0-105-chung # 152-Ubuntu SMP [...] x86_64 x86_64 x86_64 GNU / Linux *

Đầu tiên, tôi muốn kiểm tra hiệu năng EBS thô. Sử dụng một biến thể của fiolệnh ở trên, tôi đã đưa ra câu thần chú bên dưới. Lưu ý: Tôi đang sử dụng các khối 8k vì đó là những gì tôi đã đọc PostgreSQL viết là:

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%

Hiệu suất thô cho khối lượng EBS là WRITE: io=3192.2MB.

Bây giờ, thử nghiệm XFS với cùng một fiolệnh:

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%

Đường cơ sở của chúng tôi là WRITE: io=3181.9MB; thực sự gần với tốc độ đĩa thô.

Bây giờ, vào ZFS với WRITE: io=3181.9MBtham chiếu:

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

Lưu ý, điều này thực hiện tốt hơn XFS WRITE: io=4191.7MB. Tôi khá chắc chắn rằng điều này là do nén.

Đối với các cú đá, tôi sẽ thêm một tập thứ hai:

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

Với một tập thứ hai WRITE: io=5975.9MB, vì vậy ~ 1,8 lần ghi.

Tập thứ ba cho chúng ta WRITE: io=6667.5MB, vì vậy ~ 2.1X ghi.

Và một tập thứ tư cho chúng ta WRITE: io=6552.9MB. Đối với loại trường hợp này, có vẻ như tôi gần như giới hạn mạng EBS với hai tập, chắc chắn là ba và không tốt hơn với 4 (750 * 3 = 2250 IOPS).

* Từ video này, đảm bảo bạn đang sử dụng nhân linux 3,8+ để có được tất cả sự tốt đẹp của EBS.