Linux의 ZFS가 AWS i2.8xlarge 인스턴스에서 8x SSD를 완전히 활용할 수없는 이유는 무엇입니까?

ZFS를 처음 접했으므로 시작하기 전에 간단한 동작을 수행하기 위해 간단한 벤치 마크를 수행해야한다고 생각했습니다. 성능의 한계를 뛰어 넘어 Amazon EC2 i2.8xlarge인스턴스를 프로비저닝했습니다 (시간당 약 $ 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]

4K 랜덤 쓰기를위한 57K IOPS 상당한.

그런 다음 8 개 모두에 걸친 ZFS 볼륨을 만들었습니다. 처음에는 raidz18 개의 SSD가 모두 포함 된 하나의 vdev가 있었지만 이것이 성능에 나쁜 이유에 대해 읽었 mirror으므로 다음과 같이 4 개의 vdev가 생겼 습니다 .

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

recordsize를 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]

이 ZFS 풀에는 52K IOPS 만 있습니다. 실제로 하나의 SSD 자체보다 약간 나쁩니다.

내가 여기서 뭘 잘못하고 있는지 이해할 수 없습니다. ZFS를 잘못 구성 했습니까, 아니면 ZFS 성능이 좋지 않은 테스트입니까?

참고 4.4.5 elrepo 커널로 업그레이드했지만 공식 64 비트 CentOS 7 HVM 이미지를 사용하고 있습니다.

$ 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를 설치 했습니다 . zfs패키지 0.6.5.5 버전이 있습니다 .

업데이트 : @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 코어가 있으며 CPU 사용량이 80 %로 급증합니다. 배고픈 과정? z_wr_iss, 그것의 많은 인스턴스.

압축이 해제되어 압축 엔진이 아닙니다.

나는 raidz를 사용하지 않으므로 패리티 계산이되어서는 안됩니다.

나는 않았다 perf top그것은에서 보낸 커널 대부분의 시간을 보여줍니다 _raw_spin_unlock_irqrestore에서 z_wr_int_4와 osq_lock의를 z_wr_iss.

나는이 성능 병목 현상에 CPU 구성 요소가 있다고 생각하지만 그것이 무엇인지 파악하는 데 더 가깝지는 않습니다.

업데이트 2 : @ewwhite와 다른 사람들의 제안에 따르면 성능 불확실성을 생성하는 것은이 환경의 가상화 된 특성이므로 환경의 fio4 개의 SSD에 분산 된 임의의 4K 쓰기를 벤치 마크 하는 데 사용 했습니다. 각 SSD 자체는 ~ 55K IOPS를 제공하므로 4 개에서 약 240K IO가 필요합니다. 그것은 내가 얻는 것보다 다소 적습니다.

$ 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가 구현되는 방식은 최고 속도에 도달하지 못하도록하는 것입니다. 나는 그것이 무엇인지 알 수 없습니다.

이 설정이 제대로 조정되지 않았을 수 있습니다. SSD 사용시 /etc/modprobe/zfs.conf 파일과 ashift 값 모두에 필요한 매개 변수가 있습니다

ashift = 12 또는 13을 시도하고 다시 테스트하십시오.

편집하다:

이것은 여전히 ​​가상화 된 솔루션이므로 기본 하드웨어 또는 모든 요소가 상호 연결되는 방식에 대해 너무 많이 알지 못합니다. 이 솔루션으로 더 나은 성능을 얻을 수 있을지 모르겠습니다.

편집하다:

이런 식으로 클라우드 인스턴스를 최적화하려는 시점이 보이지 않는 것 같습니다. 최고의 성능이 목표라면 하드웨어를 사용하게 될 것입니다.

그러나 ZFS에는 조정 가능한 많은 설정이 있으며 기본적으로 얻는 것은 사용 사례와 가까운 곳이 아닙니다.

다음을 시도 /etc/modprobe.d/zfs.conf하고 재부팅하십시오. 응용 프로그램 서버의 모든 SSD 데이터 풀에서 사용하는 것입니다. 교대조는 12 또는 13이어야합니다. compression = off 인 벤치 마크이지만 프로덕션에서는 compression = 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

Linux 커널 뮤텍스 잠금을 기다리고 Xen 링 버퍼를 기다리고있는 것 같습니다. 비슷한 머신에 액세스하지 않고는 이것을 확신 할 수 없지만 해당 권한에 대해 시간당 Amazon $ 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 -웹에서 읽어보십시오. 이것은 Postgres에 더 좋습니다.

recordsize=8k -PG 특정 8k 블록 크기

sync=standard-동기화를 해제하려고했습니다. 많은 혜택을 보지 못했다

아래의 테스트는 XFS 성능보다 우수합니다 (테스트에서 오류가 표시되면 의견을 보내주십시오!).

이것으로 다음 단계는 2 x EBS ZFS 파일 시스템에서 Postgres를 실행하는 것입니다.

내 특정 설정 :

EC2 : m4.xlarge인스턴스

EBS : 250GB gp2볼륨

커널 : Linux [...] 3.13.0-105-generic # 152-Ubuntu SMP [...] x86_64 x86_64 x86_64 GNU / Linux *

먼저 원시 EBS 성능을 테스트하고 싶었습니다. fio위 의 명령을 변형하여 아래의 명령을 내 렸습니다. 참고 : PostgreSQL 쓰기를 읽은 것이 8k 블록을 사용하고 있습니다.

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입니다.

이제 동일한 fio명령으로 XFS를 테스트하십시오 .

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

이것은 XFS보다 성능이 뛰어납니다 WRITE: io=4191.7MB. 나는 이것이 압축 때문이라고 확신합니다.

차기에는 두 번째 볼륨을 추가하겠습니다.

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 네트워크를 거의 모자를 씌운 것 같습니다. 분명히 3을 사용하면 4 (750 * 3 = 2250 IOPS)로는 더 나아지지 않습니다.

* 이 비디오 에서 3.8+ Linux 커널을 사용하여 모든 EBS 장점을 얻으십시오.