Pourquoi ZFS sous Linux ne peut-il pas utiliser pleinement les SSD 8x sur l'instance AWS i2.8xlarge?

Je suis complètement nouveau sur ZFS, donc pour commencer, je pensais que je ferais quelques repères simples dessus pour avoir une idée de son comportement. Je voulais repousser les limites de ses performances alors j'ai provisionné une i2.8xlargeinstance Amazon EC2 (près de 7 $ / h, le temps c'est vraiment de l'argent!). Cette instance dispose de 8 SSD de 800 Go.

J'ai fait un fiotest sur les SSD eux-mêmes et j'ai obtenu la sortie suivante (découpée):

$ 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 pour les écritures aléatoires 4K. Respectable.

J'ai ensuite créé un volume ZFS couvrant tous les 8. Au début, j'avais un raidz1vdev avec tous les 8 SSD, mais j'ai lu les raisons pour lesquelles cela est mauvais pour les performances, donc je me suis retrouvé avec quatre mirrorvdev, comme ceci:

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

J'ai réglé la taille d'enregistrement sur 4K et j'ai exécuté mon 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]

Je reçois seulement 52K IOPS sur ce pool ZFS. C'est en fait légèrement pire qu'un SSD lui-même.

Je ne comprends pas ce que je fais mal ici. Ai-je mal configuré ZFS, ou s'agit-il d'un mauvais test des performances ZFS?

Remarque J'utilise l'image officielle HVM CentOS 7 64 bits, bien que j'ai mis à niveau vers le noyau 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

J'ai installé ZFS à partir du dépôt zfs répertorié ici . J'ai la version 0.6.5.5 du zfspaquet.

MISE À JOUR : Selon la suggestion de @ ewwhite, j'ai essayé ashift=12et ashift=13:

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

et

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

Aucun de ces éléments n'a fait de différence. D'après ce que je comprends, les derniers bits ZFS sont suffisamment intelligents pour identifier les SSD 4K et utiliser des valeurs par défaut raisonnables.

J'ai cependant remarqué que l'utilisation du processeur augmente. @Tim l'a suggéré mais je l'ai rejeté mais je pense que je n'ai pas regardé le CPU assez longtemps pour le remarquer. Il y a quelque chose comme 30 cœurs de processeur sur cette instance, et l'utilisation du processeur atteint 80%. Le processus de la faim? z_wr_iss, beaucoup d'exemples.

J'ai confirmé que la compression était désactivée, ce n'est donc pas le moteur de compression.

Je n'utilise pas raidz, donc ce ne devrait pas être le calcul de parité.

Je l' ai fait une perf topet il montre la plupart du temps du noyau passé dans _raw_spin_unlock_irqrestoreen z_wr_int_4et osq_locken z_wr_iss.

Je crois maintenant qu'il y a un composant CPU dans ce goulot d'étranglement des performances, bien que je ne sois pas plus près de comprendre ce qu'il pourrait être.

MISE À JOUR 2 : Selon @ewwhite et d'autres suggérant que c'est la nature virtualisée de cet environnement qui crée une incertitude de performance, j'ai utilisé fiopour comparer les écritures 4K aléatoires réparties sur quatre des SSD de l'environnement. Chaque SSD à lui seul donne ~ 55K IOPS, donc je m'attendais à quelque 240K IO sur quatre d'entre eux. C'est plus ou moins ce que j'ai obtenu:

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

Cela montre clairement que l'environnement, aussi virtualisé soit-il, peut soutenir les IOPS beaucoup plus haut que ce que je vois. Quelque chose sur la façon dont ZFS est implémenté l'empêche d'atteindre la vitesse maximale. Je ne peux pas comprendre ce que c'est.

Cette configuration peut ne pas être bien réglée. Des paramètres sont nécessaires pour le fichier /etc/modprobe/zfs.conf et la valeur ashift lors de l'utilisation de disques SSD

Essayez ashift = 12 ou 13 et testez à nouveau.

Éditer:

Il s'agit toujours d'une solution virtualisée, nous ne savons donc pas grand-chose sur le matériel sous-jacent ou comment tout est interconnecté. Je ne sais pas que vous obtiendrez de meilleures performances de cette solution.

Éditer:

Je suppose que je ne vois pas l'intérêt d'essayer d'optimiser une instance de cloud de cette manière. Parce que si les meilleures performances étaient l'objectif, vous utiliseriez du matériel, non?

Mais rappelez-vous que ZFS a beaucoup de paramètres ajustables, et ce que vous obtenez par défaut n'est pas proche de votre cas d'utilisation.

Essayez ce qui suit dans votre /etc/modprobe.d/zfs.confet redémarrez. C'est ce que j'utilise dans mes pools de données entièrement SSD pour les serveurs d'applications. Votre ashift doit être de 12 ou 13. Benchmark avec compression = off, mais utilisez compression = lz4 en production. Réglez atime = off. Je laisserais la taille d'enregistrement par défaut (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

Il semble probable que vous attendiez un verrou mutex du noyau Linux qui, à son tour, pourrait attendre un tampon en anneau Xen. Je ne peux pas en être certain sans avoir accès à une machine similaire, mais je ne suis pas intéressé à payer à Amazon 7 $ / heure pour ce privilège.

La rédaction plus longue est ici: https://www.reddit.com/r/zfs/comments/4b4r1y/why_is_zfs_on_linux_unable_to_fully_utilize_8x/d1e91wo ; Je préfère que ce soit à un endroit plutôt qu'à deux.

J'ai passé beaucoup de temps à essayer de retrouver cela. Mon défi spécifique: un serveur Postgres et je veux utiliser ZFS pour son volume de données. La base de référence est XFS.

D'abord et avant tout, mes épreuves me disent que ashift=12c'est faux. S'il y a un ashiftchiffre magique, ce n'est pas 12. J'utilise 0et j'obtiens de très bons résultats.

J'ai également expérimenté un tas d'options zfs et celles qui me donnent les résultats ci-dessous sont:

atime=off - Je n'ai pas besoin de temps d'accès

checksum=off - Je me déshabille, pas en miroir

compression=lz4- Les performances sont meilleures avec la compression (compromis CPU?)

exec=off - C'est pour les données, pas les exécutables

logbias=throughput - Lisez sur les interwebs c'est mieux pour Postgres

recordsize=8k - Taille de bloc 8k spécifique à PG

sync=standard- essayé de désactiver la synchronisation; n'a pas vu beaucoup d'avantages

Mes tests ci-dessous montrent mieux que les performances XFS (veuillez commenter si vous voyez des erreurs dans mes tests!).

Avec cela, ma prochaine étape est d'essayer Postgres fonctionnant sur un système de fichiers 2 x EBS ZFS.

Ma configuration spécifique:

EC2: m4.xlargeinstance

EBS: 250 Go de gp2volumes

noyau: Linux [...] 3.13.0-105-générique # 152-Ubuntu SMP [...] x86_64 x86_64 x86_64 GNU / Linux *

Tout d'abord, je voulais tester les performances brutes d'EBS. En utilisant une variation de la fiocommande ci-dessus, j'ai trouvé l'incantation ci-dessous. Remarque: j'utilise des blocs de 8k car c'est ce que j'ai lu, les écritures PostgreSQL sont:

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%

La performance brute pour le volume EBS est WRITE: io=3192.2MB.

Maintenant, testons XFS avec la même fiocommande:

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%

Notre base de référence est WRITE: io=3181.9MB; vraiment proche de la vitesse du disque brut.

Maintenant, sur ZFS avec WRITE: io=3181.9MBcomme référence:

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

Remarquez, cela fonctionnait mieux que XFS WRITE: io=4191.7MB. Je suis sûr que cela est dû à la compression.

Pour les coups de pied, je vais ajouter un deuxième volume:

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

Avec un deuxième volume, WRITE: io=5975.9MBdonc ~ 1,8X les écritures.

Un troisième volume nous donne WRITE: io=6667.5MB, donc ~ 2.1X les écritures.

Et un quatrième volume nous donne WRITE: io=6552.9MB. Pour ce type d'instance, il semble que je plafonne presque le réseau EBS avec deux volumes, certainement avec trois et ce n'est pas mieux avec 4 (750 * 3 = 2250 IOPS).

* À partir de cette vidéo, assurez-vous que vous utilisez le noyau Linux 3.8+ pour obtenir toutes les qualités EBS.