Warum kann ZFS unter Linux 8x SSDs auf einer AWS i2.8xlarge-Instanz nicht vollständig nutzen?

Ich bin völlig neu in ZFS, also dachte ich zuerst, ich würde ein paar einfache Benchmarks machen, um ein Gefühl dafür zu bekommen, wie es sich verhält. Ich wollte die Grenzen seiner Leistung erweitern, also habe ich eine Amazon EC2- i2.8xlargeInstanz bereitgestellt (fast 7 US-Dollar pro Stunde, Zeit ist wirklich Geld!). Diese Instanz verfügt über 8 SSDs mit 800 GB.

Ich habe fiodie SSDs selbst getestet und die folgende Ausgabe erhalten (abgeschnitten):

$ 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 für zufällige 4K-Schreibvorgänge. Seriös.

Ich habe dann ein ZFS-Volume erstellt, das sich über alle 8 erstreckt. Zuerst hatte ich einen raidz1vdev mit allen 8 SSDs, aber ich habe gelesen, warum dies für die Leistung schlecht ist . Am Ende hatte ich also vier mirrorvdevs, wie folgt:

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

Ich stellte die Aufzeichnungsgröße auf 4K ein und führte meinen Test durch:

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

Ich erhalte nur 52.000 IOPS für diesen ZFS-Pool. Das ist eigentlich etwas schlimmer als eine SSD selbst.

Ich verstehe nicht, was ich hier falsch mache. Habe ich ZFS falsch konfiguriert oder ist dies ein schlechter Test für die ZFS-Leistung?

Hinweis Ich verwende das offizielle 64-Bit-CentOS 7 HVM-Image, obwohl ich auf den elrepo-Kernel 4.4.5 aktualisiert habe:

$ 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

Ich habe ZFS aus dem hier aufgelisteten ZFS-Repository installiert . Ich habe Version 0.6.5.5 des zfsPakets.

UPDATE : Per @ ewwhite's Vorschlag habe ich versucht ashift=12und ashift=13:

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

und

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

Beides machte keinen Unterschied. Soweit ich weiß, sind die neuesten ZFS-Bits intelligent genug, um 4K-SSDs zu identifizieren und angemessene Standardeinstellungen zu verwenden.

Mir ist jedoch aufgefallen, dass die CPU-Auslastung stark ansteigt. @Tim schlug dies vor, aber ich lehnte es ab, aber ich glaube, ich habe die CPU nicht lange genug beobachtet, um es zu bemerken. In dieser Instanz befinden sich etwa 30 CPU-Kerne, und die CPU-Auslastung steigt auf bis zu 80%. Der hungrige Prozess? z_wr_issviele Instanzen davon.

Ich habe bestätigt, dass die Komprimierung deaktiviert ist, es handelt sich also nicht um die Komprimierungsengine.

Ich verwende kein Raidz, daher sollte es nicht die Paritätsberechnung sein.

Ich habe eine gemacht perf topund es zeigt den größten Teil der Kernel-Zeit, die _raw_spin_unlock_irqrestorein z_wr_int_4und osq_lockin verbracht wurde z_wr_iss.

Ich glaube jetzt, dass dieser Leistungsengpass eine CPU-Komponente hat, obwohl ich nicht näher dran bin, herauszufinden, was das sein könnte.

UPDATE 2 : Per @ewwhite und dem Vorschlag anderer, dass es die virtualisierte Natur dieser Umgebung ist, die zu Performance-Unsicherheiten führt, habe ich fiozufällige 4K-Schreibvorgänge verglichen, die auf vier der SSDs in der Umgebung verteilt sind. Jede SSD für sich gibt ~ 55K IOPS, so dass ich ungefähr 240K IOs für vier von ihnen erwartet habe. Das ist mehr oder weniger was ich habe:

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

Dies zeigt deutlich, dass die Umgebung, auch wenn sie virtualisiert ist, die IOPS viel besser aushält als ich sie sehe. Etwas an der Art und Weise, wie ZFS implementiert wird, hindert es daran, die Höchstgeschwindigkeit zu erreichen. Ich kann einfach nicht herausfinden, was das ist.

Dieses Setup ist möglicherweise nicht gut abgestimmt. Bei Verwendung von SSDs sind Parameter sowohl für die Datei /etc/modprobe/zfs.conf als auch für den Wert ashift erforderlich

Versuchen Sie es mit ashift = 12 oder 13 und wiederholen Sie den Test.

Bearbeiten:

Dies ist immer noch eine virtualisierte Lösung, daher wissen wir nicht viel über die zugrunde liegende Hardware oder wie alles miteinander verbunden ist. Ich weiß nicht, dass Sie mit dieser Lösung eine bessere Leistung erzielen.

Bearbeiten:

Ich denke, ich sehe keinen Sinn darin, eine Cloud-Instanz auf diese Weise zu optimieren. Denn wenn Top-Performance das Ziel wäre, würden Sie Hardware verwenden, oder?

Denken Sie jedoch daran, dass ZFS viele anpassbare Einstellungen hat und das, was Sie standardmäßig erhalten, nicht in der Nähe Ihres Anwendungsfalls liegt.

Versuchen Sie Folgendes in Ihrem /etc/modprobe.d/zfs.confund starten Sie neu. Dies verwende ich in meinen All-SSD-Datenpools für Anwendungsserver. Ihre Schicht sollte 12 oder 13 sein. Benchmark mit Komprimierung = aus, aber verwenden Sie Komprimierung = lz4 in der Produktion. Setze atime = off. Ich würde Recordsize als Standard (128K) belassen.

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

Es ist wahrscheinlich, dass Sie auf ein Linux-Kernel-Mutex-Schloss warten, das wiederum auf einen Xen-Ringpuffer wartet. Ohne Zugang zu einem ähnlichen Computer kann ich mir das nicht sicher sein, aber ich bin nicht daran interessiert, Amazon 7 USD / Stunde für dieses Privileg zu bezahlen.

Weitere Informationen finden Sie hier: https://www.reddit.com/r/zfs/comments/4b4r1y/why_is_zfs_on_linux_unable_to_fully_utilize_8x/d1e91wo ; Ich möchte lieber an einem Ort als an zwei.

Ich habe anständig viel Zeit damit verbracht, dies aufzuspüren. Meine besondere Herausforderung: Ein Postgres-Server und ich möchten ZFS für sein Datenvolumen verwenden. Die Basis ist XFS.

In erster Linie sagen mir meine Versuche, dass ashift=12das falsch ist. Wenn es eine magische ashiftZahl gibt, ist sie nicht 12. Ich benutze sie 0und erhalte sehr gute Ergebnisse.

Ich habe auch mit einer Reihe von ZFS-Optionen experimentiert. Die Optionen, die mir die folgenden Ergebnisse liefern, sind:

atime=off - Ich brauche keine Zugriffszeiten

checksum=off - Ich streife und spiegele nicht

compression=lz4- Leistung ist mit Komprimierung besser (CPU-Kompromiss?)

exec=off - Dies ist für Daten gedacht, nicht für ausführbare Dateien

logbias=throughput - Lesen Sie in den Zwischenwebs nach, dass dies für Postgres besser ist

recordsize=8k - PG-spezifische 8k-Blockgröße

sync=standard- hat versucht, die Synchronisierung auszuschalten; sah nicht viel Nutzen

Meine Tests unten zeigen eine bessere Leistung als XFS (bitte kommentieren Sie, wenn Sie Fehler in meinen Tests sehen!).

Als nächstes versuche ich, Postgres auf einem 2 x EBS ZFS-Dateisystem auszuführen.

Mein spezielles Setup:

EC2: m4.xlargeInstanz

EBS: 250 GB gp2Volumes

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

Zuerst wollte ich die EBS-Leistung testen. Unter Verwendung einer Variation des fioobigen Befehls kam ich auf die Beschwörung unten. Hinweis: Ich verwende 8k-Blöcke, da ich gelesen habe, dass PostgreSQL-Schreibvorgänge wie folgt lauten:

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%

Die Rohleistung für das EBS-Volume beträgt WRITE: io=3192.2MB.

Testen Sie nun XFS mit demselben fioBefehl:

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%

Unsere Grundlinie ist WRITE: io=3181.9MB; sehr nahe an der Geschwindigkeit der Rohplatte.

Nun auf ZFS mit WRITE: io=3181.9MBals Referenz:

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

Beachten Sie, dass dies besser funktioniert als XFS WRITE: io=4191.7MB. Ich bin mir ziemlich sicher, dass dies auf die Komprimierung zurückzuführen ist.

Für Kicks werde ich einen zweiten Band hinzufügen:

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

Mit einem zweiten Band, WRITE: io=5975.9MBalso ~ 1,8X, schreibt das.

Ein dritter Band gibt uns WRITE: io=6667.5MBalso ~ das 2,1-fache des Schreibens.

Und ein vierter Band gibt uns WRITE: io=6552.9MB. Für diesen Instanztyp sehe ich so aus, als würde ich das EBS-Netzwerk fast mit zwei Volumes begrenzen, definitiv mit drei und es ist nicht besser mit 4 (750 * 3 = 2250 IOPS).

* In diesem Video stellen Sie sicher, dass Sie einen Linux-Kernel mit 3.8+ verwenden, um alle Vorteile von EBS zu nutzen.