Dlaczego ZFS w systemie Linux nie jest w stanie w pełni wykorzystać 8x dysków SSD w instancji AWS i2.8xlarge?

Jestem zupełnie nowy w ZFS, więc na początek pomyślałem, że zrobię kilka prostych testów porównawczych, aby poczuć, jak się zachowuje. Chciałem przekroczyć granice jego wydajności, więc przygotowałem i2.8xlargeinstancję Amazon EC2 (prawie 7 USD / godzinę, czas to naprawdę pieniądze!). Ta instancja ma 8 800 GB dysków SSD.

Zrobiłem fiotest na samych dyskach SSD i uzyskałem następujące dane wyjściowe (przycięte):

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

57 000 IOPS dla losowych zapisów 4K. Poważny.

Następnie utworzyłem wolumin ZFS obejmujący wszystkie 8. Na początku miałem jeden raidz1vdev ze wszystkimi 8 dyskami SSD, ale czytałem o powodach, dla których jest to niekorzystne z punktu widzenia wydajności, więc skończyłem z czterema mirrorvdevami, takimi jak:

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

Ustawiłem rozmiar rekordu na 4K i uruchomiłem test:

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

W tej puli ZFS otrzymuję tylko 52 KB IOPS. To właściwie nieco gorzej niż sam dysk SSD.

Nie rozumiem, co robię źle tutaj. Czy źle skonfigurowałem ZFS, czy jest to zły test wydajności ZFS?

Uwaga: Używam oficjalnego 64-bitowego obrazu CentOS 7 HVM, chociaż zaktualizowałem do jądra elrepo 4.4.5:

$ 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

Zainstalowałem ZFS z wymienionego tutaj repozytorium zfs . Mam wersję 0.6.5.5 zfspakietu.

AKTUALIZACJA : Zgodnie z sugestią @ ewwhite próbowałem ashift=12i ashift=13:

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

i

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

Żadne z nich nie miało znaczenia. Z tego, co rozumiem, najnowsze bity ZFS są wystarczająco inteligentne do identyfikowania dysków SSD 4K i używania rozsądnych ustawień domyślnych.

Zauważyłem jednak, że użycie procesora gwałtownie wzrasta. @Tim zasugerował to, ale odrzuciłem to, ale myślę, że nie obserwowałem procesora wystarczająco długo, aby to zauważyć. W tym przypadku jest około 30 rdzeni procesora, a użycie procesora wzrasta aż o 80%. Głodny proces? z_wr_iss, wiele jego przypadków.

Potwierdziłem, że kompresja jest wyłączona, więc nie jest to silnik kompresji.

Nie używam raidz, więc nie powinno to być obliczanie parzystości.

Zrobiłem perf topi to widać przez większość czasu spędzonego w jądra _raw_spin_unlock_irqrestorew z_wr_int_4i osq_lockw z_wr_iss.

Teraz uważam, że w tym wąskim gardle jest element procesora, choć nie jestem bliżej zastanowienia się, co to może być.

AKTUALIZACJA 2 : Zgodnie z sugestią @ewwhite i innych, że to zwirtualizowana natura tego środowiska powoduje niepewność wydajności, użyłem fiodo testowania losowych zapisów 4K rozproszonych na czterech dyskach SSD w środowisku. Każdy dysk SSD sam daje ~ 55 000 operacji we / wy, więc spodziewałem się około 240 000 operacji we / wy na czterech z nich. To mniej więcej to, co mam:

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

To wyraźnie pokazuje, że środowisko, choć może być zwirtualizowane, może utrzymać IOPS znacznie wyżej niż to, co widzę. Coś w sposobie implementacji ZFS uniemożliwia mu osiągnięcie maksymalnej prędkości. Po prostu nie mogę zrozumieć, co to jest.

Ta konfiguracja może nie być dostrojona. Istnieją parametry potrzebne zarówno dla pliku /etc/modprobe/zfs.conf, jak i wartości Ashift podczas korzystania z dysków SSD

Spróbuj ashift = 12 lub 13 i przetestuj ponownie.

Edytować:

To wciąż zwirtualizowane rozwiązanie, więc nie wiemy zbyt wiele o sprzęcie bazowym ani o tym, jak wszystko jest ze sobą powiązane. Nie wiem, czy dzięki temu rozwiązaniu uzyskasz lepszą wydajność.

Edytować:

Chyba nie ma sensu próbować optymalizować wystąpienia chmury w ten sposób. Ponieważ gdyby celem była najwyższa wydajność, używałbyś sprzętu, prawda?

Pamiętaj jednak, że ZFS ma wiele dostrajalnych ustawień, a to, co dostajesz domyślnie, nie jest nigdzie blisko twojego przypadku użycia.

Wypróbuj poniższe /etc/modprobe.d/zfs.confi uruchom ponownie. To jest to, czego używam w moich pulach danych SSD dla serwerów aplikacji. Twoje przesunięcie popiołu powinno wynosić 12 lub 13. Benchmark z kompresją = wyłączony, ale użyj kompresji = lz4 w produkcji. Ustaw atime = wyłączony. Domyślnie pozostawiłbym rozmiar rekordu (128 KB).

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

Wydaje się prawdopodobne, że czekasz na blokadę mutex jądra Linux, która z kolei może oczekiwać na bufor pierścieniowy Xen. Nie mogę być tego pewien bez dostępu do podobnej maszyny, ale nie jestem zainteresowany płaceniem Amazonowi 7 USD / godzinę za ten przywilej.

Dłuższy zapis jest tutaj: https://www.reddit.com/r/zfs/comments/4b4r1y/why_is_zfs_on_linux_unable_to_fully_utilize_8x/d1e91wo ; Wolałbym, żeby był w jednym miejscu niż w dwóch.

Sporo czasu poświęciłem na śledzenie tego. Moje szczególne wyzwanie: serwer Postgres i chcę używać ZFS do objętości danych. Podstawą jest XFS.

Przede wszystkim moje próby mówią mi, że ashift=12to źle. Jeśli jest jakaś magiczna ashiftliczba, nie jest to 12. Używam 0i uzyskuję bardzo dobre wyniki.

Eksperymentowałem również z wieloma opcjami ZFS, a te, które dają mi poniższe wyniki to:

atime=off - Nie potrzebuję czasów dostępu

checksum=off - Rozbieram się, nie lustro

compression=lz4- Wydajność jest lepsza przy kompresji (kompromis procesora?)

exec=off - To dotyczy danych, a nie plików wykonywalnych

logbias=throughput - Czytaj na stronach internetowych, to jest lepsze dla Postgres

recordsize=8k - Rozmiar bloku 8k właściwy dla PG

sync=standard- próbował wyłączyć synchronizację; nie widziałem wiele korzyści

Moje poniższe testy wykazują lepszą wydajność niż XFS (proszę o komentarz, jeśli zobaczysz błędy w moich testach!).

W tym kroku moim kolejnym krokiem jest wypróbowanie Postgresa na systemie plików 2 x EBS ZFS.

Moja konkretna konfiguracja:

EC2: m4.xlargeinstancja

EBS: gp2woluminy 250 GB

jądro: Linux [...] 3.13.0-105-generic # 152-Ubuntu SMP [...] x86_64 x86_64 x86_64 GNU / Linux *

Najpierw chciałem przetestować surową wydajność EBS. Korzystając z odmiany fiopowyższego polecenia, wymyśliłem inkantację poniżej. Uwaga: używam bloków 8k, ponieważ to, co przeczytałem, pisze 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%

Surowa wydajność woluminu EBS wynosi WRITE: io=3192.2MB.

Teraz testujemy XFS za pomocą tego samego fiopolecenia:

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%

Naszym punktem odniesienia jest WRITE: io=3181.9MB; bardzo zbliżone do prędkości dysku.

Teraz na ZFS WRITE: io=3181.9MBjako odniesienie:

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

Zauważ, że działało to lepiej niż XFS WRITE: io=4191.7MB. Jestem prawie pewien, że jest to spowodowane kompresją.

W przypadku kopnięć dodam drugi tom:

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

Z drugim tomem WRITE: io=5975.9MB, więc ~ 1.8X pisze.

Trzeci tom daje nam WRITE: io=6667.5MB, więc ~ 2.1X pisze.

I daje nam czwarty tom WRITE: io=6552.9MB. W przypadku tego typu instancji wygląda to tak, jakbym prawie zamknął sieć EBS dwoma woluminami, zdecydowanie trzema, i nie jest lepiej z 4 (750 * 3 = 2250 IOPS).

* Z tego filmu upewnij się, że używasz jądra linuksa w wersji 3.8+, aby uzyskać wszystkie zalety EBS.