Perché ZFS su Linux non è in grado di utilizzare completamente 8x SSD su istanza AWS i2.8xlarge?


12

Sono completamente nuovo in ZFS, quindi all'inizio ho pensato di fare alcuni semplici benchmark per avere un'idea di come si comporta. Volevo spingere i limiti delle sue prestazioni, quindi ho eseguito il provisioning di i2.8xlargeun'istanza Amazon EC2 (quasi $ 7 / ora, il tempo è davvero denaro!). Questa istanza ha 8 SSD da 800 GB.

Ho fatto un fiotest sugli stessi SSD e ho ottenuto il seguente output (tagliato):

$ 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 per scritture casuali 4K. Rispettabile.

Ho quindi creato un volume ZFS che copre tutti gli 8. All'inizio avevo un raidz1vdev con tutti gli 8 SSD, ma ho letto i motivi per cui questo è negativo per le prestazioni, quindi ho finito con quattro mirrorvdev, in questo modo:

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

Ho impostato il recordsize su 4K ed ho eseguito il mio 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]

Ottengo solo 52.000 IOPS su questo pool ZFS. In realtà è leggermente peggio di un SSD stesso.

Non capisco cosa sto facendo di sbagliato qui. Ho configurato ZFS in modo errato o è un test scarso delle prestazioni di ZFS?

Nota: sto usando l'immagine HVM CentOS 7 ufficiale a 64 bit, anche se ho aggiornato il kernel 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

Ho installato ZFS dal repository zfs elencato qui . Ho la versione 0.6.5.5 del zfspacchetto.

AGGIORNAMENTO : Per il suggerimento di @ ewwhite ho provato ashift=12e ashift=13:

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

e

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

Nessuno di questi ha fatto alcuna differenza. Da quello che ho capito, gli ultimi bit ZFS sono abbastanza intelligenti nell'identificare SSD 4K e usando valori predefiniti ragionevoli.

Ho notato tuttavia che l'utilizzo della CPU sta aumentando. @Tim ha suggerito questo, ma l'ho scartato ma penso che non stavo guardando la CPU abbastanza a lungo da notare. Ci sono qualcosa come 30 core di CPU in questa istanza e l'utilizzo della CPU aumenta fino all'80%. Il processo della fame? z_wr_iss, molti esempi.

Ho confermato che la compressione è disattivata, quindi non è il motore di compressione.

Non sto usando raidz, quindi non dovrebbe essere il calcolo della parità.

Ho fatto un perf tope mostra la maggior parte del tempo del kernel trascorso _raw_spin_unlock_irqrestoredentro z_wr_int_4e osq_lockdentro z_wr_iss.

Ora credo che ci sia un componente CPU in questo collo di bottiglia delle prestazioni, anche se non sono più vicino a capire quale potrebbe essere.

AGGIORNAMENTO 2 : Per @ewwhite e il suggerimento di altri che è la natura virtualizzata di questo ambiente che crea incertezza delle prestazioni, ho usato fioper confrontare le scritture 4K casuali distribuite su quattro degli SSD nell'ambiente. Ogni SSD da solo fornisce ~ 55K IOPS, quindi mi aspettavo da qualche parte circa 240K IO su quattro di essi. Questo è più o meno quello che ho ottenuto:

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

Ciò dimostra chiaramente che l'ambiente, per quanto virtualizzato possa essere, può sostenere gli IOPS molto più in alto di quello che sto vedendo. Qualcosa sul modo in cui viene implementato ZFS è impedirgli di raggiungere la massima velocità. Non riesco proprio a capire cosa sia.


Sei su EC2. Ottieni solo tutti gli IOPS che Amazon vuole darti.
Michael Hampton

Amazon mi dà circa 52K IOPS per SSD collegati a questa istanza e ci sono otto di questi SSD collegati. Dai documenti di Amazon è chiaro che un'istanza di queste dimensioni è l'unica istanza in esecuzione sull'host fisico in cui risiede. Inoltre si tratta di SSD locali, NON di volumi EBS, quindi non vi sono altri carichi di lavoro che contendono la larghezza di banda IO. Questo non spiega la performance che sto vedendo.
anelson

Sta tassando la CPU o sta colpendo i limiti di memoria?
Tim

Hai letto questa serie di articoli? hatim.eu/2014/2014/24/… Hai mai aiutato altri articoli?
Tim

1
Giusto per escludere le effettive carenze di implementazione di zfsonlinux, proverei lo stesso banco di prova con un'installazione di Solaris 11 sulla stessa istanza.
the-wabbit

Risposte:


6

Questa configurazione potrebbe non essere ottimizzata. Ci sono parametri necessari sia per il file /etc/modprobe/zfs.conf che per il valore ashift quando si usano SSD

Prova ashift = 12 o 13 e riprova.


Modificare:

Questa è ancora una soluzione virtualizzata, quindi non sappiamo troppo sull'hardware sottostante o su come tutto sia interconnesso. Non so che otterrai prestazioni migliori da questa soluzione.


Modificare:

Immagino di non vedere il punto di provare a ottimizzare un'istanza cloud in questo modo. Perché se le prestazioni migliori fossero l'obiettivo, useresti l'hardware, giusto?

Ma ricorda che ZFS ha molte impostazioni sintonizzabili e che cosa ottieni di default non è affatto vicino al tuo caso d'uso.

Prova quanto segue nel tuo /etc/modprobe.d/zfs.confe riavvia. È quello che uso nei miei pool di dati tutto SSD per i server delle applicazioni. Il tuo ashift dovrebbe essere 12 o 13. Benchmark con la compressione = off, ma usa la compressione = lz4 in produzione. Set atime = off. Lascerei recordsize come predefinito (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

Ottimo consiglio Ho aggiornato la mia domanda originale con maggiori dettagli. Riepilogo: ashift non ha aiutato, e penso che ci sia un componente di utilizzo della CPU a questo problema.
anelson,

Stai utilizzando la compressione o la dedupe?
ewwhite,

no, ho confermato che la compressione è disattivata con zfs get compression. Anche Dedupe è spento.
anelson,

Questo è un punto giusto, ma posso dimostrare che i dispositivi di archiviazione virtualizzati sottostanti funzionano molto meglio. Vedi aggiornamento 2 sul post.
anelson,

@anelson Ok. Prova le impostazioni sopra.
ewwhite,


1

Ho trascorso una discreta quantità di tempo cercando di rintracciarlo. La mia sfida specifica: un server Postgres e voglio usare ZFS per il suo volume di dati. La linea di base è XFS.

Innanzitutto, le mie prove mi dicono che ashift=12è sbagliato. Se c'è qualche ashiftnumero magico non è 12. Sto usando 0e sto ottenendo ottimi risultati.

Ho anche sperimentato un sacco di opzioni di zfs e quelle che mi danno i risultati di seguito sono:

atime=off - Non ho bisogno di tempi di accesso

checksum=off - Sto spogliando, non rispecchiando

compression=lz4- Le prestazioni sono migliori con la compressione (compromesso della CPU?)

exec=off - Questo è per dati, non eseguibili

logbias=throughput - Leggi su interwebs questo è meglio per Postgres

recordsize=8k - Dimensione blocco specifica per PG 8k

sync=standard- ha provato a disattivare la sincronizzazione; non ho visto molti benefici

I miei test di seguito mostrano prestazioni migliori rispetto a XFS (si prega di commentare se si vedono errori nei miei test!).

Con questo il mio prossimo passo è provare Postgres in esecuzione su un filesystem 2 x EBS ZFS.

La mia configurazione specifica:

EC2: m4.xlargeistanza

EBS: gp2volumi da 250 GB

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

Innanzitutto, volevo testare le prestazioni EBS non elaborate. Usando una variante del fiocomando sopra, ho trovato l'incantesimo sotto. Nota: sto usando blocchi 8k perché è quello che ho letto che le scritture PostgreSQL sono:

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%

Le prestazioni non elaborate per il volume EBS sono WRITE: io=3192.2MB.

Ora, testando XFS con lo stesso fiocomando:

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%

La nostra linea di base è WRITE: io=3181.9MB; molto vicino alla velocità del disco grezzo.

Ora, su ZFS con WRITE: io=3181.9MBcome riferimento:

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

Nota, questo ha funzionato meglio di XFS WRITE: io=4191.7MB. Sono abbastanza sicuro che ciò sia dovuto alla compressione.

Per i calci, aggiungerò un secondo 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

Con un secondo volume, WRITE: io=5975.9MBquindi ~ 1,8 volte le scritture.

Un terzo volume ci dà WRITE: io=6667.5MB, quindi ~ 2.1X le scritture.

E un quarto volume ci dà WRITE: io=6552.9MB. Per questo tipo di istanza, mi sembra di quasi limitare la rete EBS con due volumi, sicuramente con tre e non è migliore con 4 (750 * 3 = 2250 IOPS).

* Da questo video assicurati di utilizzare il kernel linux 3.8+ per ottenere tutta la bontà di EBS.


Risultati interessanti Nota Penso che tu sia confuso WRITE: io=; non è la velocità, è la quantità di dati scritti in quel momento. Legata alla velocità solo per le prove che hanno un tempo di esecuzione fisso, ma per coerenza con gli altri parametri di riferimento è meglio concentrarsi su IOPS, iops=. Nel tuo caso i risultati sono simili Probabilmente potresti ottenere molto meglio se usi volumi EBS IOPS con provisioning e un'istanza più grande. Vedere questa pagina per i limiti EBS previsti in base alle dimensioni dell'istanza. Attenzione, le spese EBS si sommano rapidamente se non stai attento!
anelson,

Ottimo feedback, grazie @anelson! hanno esaminato gli iop con provisioning e sono molto costosi. Tuttavia, stavo valutando la possibilità di creare un piccolo volume di iops con provisioning per un volume di registro in cui è scritto ZIL e ottenere alcuni vantaggi in termini di prestazioni. Da qualche parte ho letto che lo ZIL non cresce più di quanto sia presente nella memoria e l'ho limitato a 2G in /etc/modules.d/zfs.conf. La prossima domanda sarebbe qual è il numero appropriato di iops per un'istanza di dare ec2. Guardare la pagina a cui fai riferimento è ancora complicato e non vedo prestazioni buone come lo stato dei documenti.
berto
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.