¿Por qué ZFS en Linux no puede utilizar completamente SSD 8x en la instancia de AWS i2.8xlarge?

12

Soy completamente nuevo en ZFS, así que, para empezar, pensé en hacer algunos puntos de referencia simples para tener una idea de cómo se comporta. Quería superar los límites de su rendimiento, así que aprovisioné una i2.8xlargeinstancia de Amazon EC2 (casi $ 7 / hora, ¡el tiempo realmente es dinero!). Esta instancia tiene 8 SSD de 800 GB.

Hice una fioprueba en los SSD y obtuve el siguiente resultado (recortado):

$ 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 para escrituras aleatorias 4K. Respetable.

Luego creé un volumen ZFS que abarcaba los 8. Al principio tenía un raidz1vdev con los 8 SSD, pero leí sobre las razones por las que esto es malo para el rendimiento, así que terminé con cuatro mirrorvdevs, así:

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

Configuré el tamaño de registro en 4K y ejecuté mi prueba:

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

Solo obtengo 52K IOPS en este grupo de ZFS. Eso es en realidad un poco peor que un SSD en sí.

No entiendo lo que estoy haciendo mal aquí. ¿He configurado ZFS incorrectamente o es una mala prueba del rendimiento de ZFS?

Tenga en cuenta que estoy usando la imagen oficial de CentOS 7 HVM de 64 bits, aunque he actualizado al kernel 4.4.5 elrepo:

$ 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

Instalé ZFS desde el repositorio de zfs enumerado aquí . Tengo la versión 0.6.5.5 del zfspaquete.

ACTUALIZACIÓN : Por sugerencia de @ ewwhite probé ashift=12y ashift=13:

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

y

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

Ninguno de estos hizo ninguna diferencia. Por lo que entiendo, los últimos bits ZFS son lo suficientemente inteligentes como para identificar SSD 4K y usar valores predeterminados razonables.

Sin embargo, noté que el uso de la CPU está aumentando. @Tim sugirió esto, pero lo descarté, sin embargo, creo que no estaba mirando la CPU el tiempo suficiente para notarlo. Hay algo así como 30 núcleos de CPU en esta instancia, y el uso de CPU está aumentando hasta un 80%. El proceso de hambre? z_wr_iss, muchas instancias de ello.

Confirmé que la compresión está desactivada, por lo que no es el motor de compresión.

No estoy usando raidz, por lo que no debería ser el cálculo de paridad.

Hice un perf topy muestra la mayor parte del tiempo del kernel que pasé _raw_spin_unlock_irqrestoreadentro z_wr_int_4y osq_lockadentro z_wr_iss.

Ahora creo que hay un componente de CPU en este cuello de botella de rendimiento, aunque no estoy más cerca de descubrir cuál podría ser.

ACTUALIZACIÓN 2 : Según la sugerencia de @ewwhite y otros de que es la naturaleza virtualizada de este entorno lo que crea incertidumbre sobre el rendimiento, solía fiocomparar las escrituras aleatorias 4K repartidas en cuatro de los SSD del entorno. Cada SSD por sí solo da ~ 55K IOPS, por lo que esperaba alrededor de 240K IOs en cuatro de ellos. Eso es más o menos lo que obtuve:

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

Esto muestra claramente que el entorno, por virtualizado que sea, puede mantener los IOPS mucho más altos de lo que estoy viendo. Algo sobre la forma en que se implementa ZFS es evitar que alcance la velocidad máxima. Simplemente no puedo entender qué es eso.

anelson
fuente
Estás en EC2. Solo obtienes tantos IOPS como Amazon quiere darte.
Michael Hampton
Amazon me da alrededor de 52K IOPS por SSD conectado a esta instancia, y hay ocho SSD conectados. De los documentos de Amazon está claro que una instancia de este tamaño es la única instancia que se ejecuta en el host físico donde reside. Además, estos son SSD locales, NO volúmenes EBS, por lo que no hay otras cargas de trabajo que compitan por el ancho de banda de E / S. Eso no explica el rendimiento que estoy viendo.
anelson
¿Esto está gravando la CPU o está alcanzando los límites de memoria?
Tim
¿Has leído esta serie de artículos? hatim.eu/2014/05/24/… ¿Han ayudado otros artículos?
Tim
1
Solo para descartar deficiencias de implementación reales de zfsonlinux, probaría la misma prueba de banco con una instalación de Solaris 11 en la misma instancia.
the-wabbit

Respuestas:

6

Es posible que esta configuración no esté bien ajustada. Hay parámetros necesarios tanto para el archivo /etc/modprobe/zfs.conf como para el valor ashift cuando se usan SSD

Pruebe ashift = 12 o 13 y pruebe nuevamente.


Editar:

Esta sigue siendo una solución virtualizada, por lo que no sabemos demasiado sobre el hardware subyacente o cómo todo está interconectado. No sé si obtendrás un mejor rendimiento de esta solución.


Editar:

Supongo que no veo el punto de tratar de optimizar una instancia de la nube de esta manera. Porque si el máximo rendimiento fuera el objetivo, estarías usando hardware, ¿verdad?

Pero recuerda que ZFS tiene mucho configuraciones ajustables, y lo que obtiene de forma predeterminada no está cerca de su caso de uso.

Pruebe lo siguiente en su /etc/modprobe.d/zfs.confy reinicie. Es lo que uso en mis agrupaciones de datos SSD para servidores de aplicaciones. Su cambio de ceniza debe ser 12 o 13. Punto de referencia con compresión = desactivado, pero use compresión = lz4 en producción. Establecer atime = off. Dejaría el tamaño de registro predeterminado (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
ewwhite
fuente
Gran sugerencia Actualicé mi pregunta original con más detalle. Resumen: ashift no ayudó, y creo que hay un componente de uso de CPU para este problema.
anelson
¿Estás usando compresión o deduplicación?
ewwhite
No, he confirmado que la compresión está desactivada zfs get compression. Dedupe también está apagado.
anelson
Ese es un punto justo, pero puedo mostrar que los dispositivos de almacenamiento virtualizados subyacentes funcionan mucho mejor. Ver actualización 2 en la publicación.
anelson
@anelson De acuerdo. Pruebe la configuración anterior.
ewwhite
1

He pasado una cantidad de tiempo decente tratando de rastrear esto. Mi desafío específico: un servidor Postgres y quiero usar ZFS para su volumen de datos. La línea de base es XFS.

En primer lugar, mis pruebas me dicen que eso ashift=12está mal. Si hay algún ashiftnúmero mágico , no es 12. Estoy usando 0y obtengo muy buenos resultados.

También he experimentado con un montón de opciones zfs y las que me dan los siguientes resultados son:

atime=off - No necesito tiempos de acceso

checksum=off - Me estoy desnudando, no reflejando

compression=lz4- El rendimiento es mejor con la compresión (¿compensación de CPU?)

exec=off - Esto es para datos, no ejecutables

logbias=throughput - Lea en las páginas web esto es mejor para Postgres

recordsize=8k - Tamaño de bloque 8k específico de PG

sync=standard- trató de desactivar la sincronización; no vi mucho beneficio

Mis pruebas a continuación muestran un rendimiento mejor que XFS (¡comente si ve errores en mis pruebas!).

Con esto, mi próximo paso es probar Postgres ejecutándose en un sistema de archivos 2 x EBS ZFS.

Mi configuración específica:

EC2: m4.xlargeinstancia

EBS: 250 GB gp2 volúmenes de

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

Primero, quería probar el rendimiento bruto de EBS. Usando una variación del fiocomando anterior, se me ocurrió el encantamiento a continuación. Nota: Estoy usando bloques de 8k porque eso es lo que he leído que las escrituras de PostgreSQL son:

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%

El rendimiento bruto para el volumen EBS es WRITE: io=3192.2MB.

Ahora, probando XFS con el mismo 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%

Nuestra línea de base es WRITE: io=3181.9MB; muy cerca de la velocidad del disco sin formato.

Ahora, en ZFS con WRITE: io=3181.9MBcomo referencia:

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

Tenga en cuenta que esto funcionó mejor que XFS WRITE: io=4191.7MB. Estoy bastante seguro de que esto se debe a la compresión.

Para las patadas, voy a agregar un segundo volumen:

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 segundo volumen, WRITE: io=5975.9MBentonces ~ 1.8X las escrituras.

Un tercer volumen nos da WRITE: io=6667.5MB , entonces ~ 2.1X las escrituras.

Y nos da un cuarto volumen WRITE: io=6552.9MB. Para este tipo de instancia, parece que casi limito la red EBS con dos volúmenes, definitivamente con tres y no es mejor con 4 (750 * 3 = 2250 IOPS).

* De este video, asegúrese de estar utilizando el núcleo de Linux 3.8+ para obtener toda la bondad de EBS.

berto
fuente
Resultados interesantes Tenga en cuenta que creo que ha confundido WRITE: io=; esa no es la velocidad, es la cantidad de datos escritos en ese momento. Relacionado con la velocidad sólo para pruebas de que tienen un tiempo de ejecución fija, pero por coherencia con otros puntos de referencia que es mejor centrarse en IOPS, iops=. En su caso, los resultados son similares. Probablemente podría mejorar mucho si utiliza volúmenes IOPS EBS aprovisionados y una instancia más grande. Consulte esta página para ver los límites de EBS esperados por tamaño de instancia. ¡Solo tenga cuidado, los cargos de EBS se suman rápidamente si no tiene cuidado!
anelson
Gran respuesta, gracias @anelson! miró iops aprovisionados y son muy caros. Sin embargo, estaba considerando crear un pequeño volumen iops aprovisionado para un volumen de registro donde se escribe el ZIL y lograr algunos beneficios de rendimiento. En algún lugar que leí, el ZIL no crece más de lo que está en la memoria y lo tengo limitado a 2G /etc/modules.d/zfs.conf. La siguiente pregunta sería cuál es el número apropiado de iops para una instancia de dar ec2. Mirando la página a la que hace referencia todavía es complicado, y no veo un rendimiento tan bueno como lo dicen los documentos.
berto