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.8xlarge
un'istanza Amazon EC2 (quasi $ 7 / ora, il tempo è davvero denaro!). Questa istanza ha 8 SSD da 800 GB.
Ho fatto un fio
test 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 raidz1
vdev con tutti gli 8 SSD, ma ho letto i motivi per cui questo è negativo per le prestazioni, quindi ho finito con quattro mirror
vdev, 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 zfs
pacchetto.
AGGIORNAMENTO : Per il suggerimento di @ ewwhite ho provato ashift=12
e 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 top
e mostra la maggior parte del tempo del kernel trascorso _raw_spin_unlock_irqrestore
dentro z_wr_int_4
e osq_lock
dentro 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 fio
per 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.