Lettura sequenziale lenta del pool ZFS

Ho una domanda correlata su questo problema, ma è diventata troppo complicata e troppo grande, quindi ho deciso di dividere il problema in NFS e problemi locali. Ho anche provato a chiedere questo sulla mailing list di zfs-discuss senza molto successo.

Copia lenta tra le directory NFS / CIFS sullo stesso server

Schema: come sono installato e cosa mi aspetto

1. Ho un pool ZFS con 4 dischi. ROSSO 2 TB configurato come 2 mirror con striping (RAID 10). Su Linux, zfsonlinux. Non ci sono dispositivi cache o di registro.
2. I dati sono bilanciati tra mirror (importante per ZFS)
3. Ogni disco può leggere (raw w / dd) in parallelo a 147 MB ​​/ sec, fornendo un throughput combinato di 588 MB / sec.
4. Mi aspetto circa 115 MB / sec in scrittura, 138 MB / sec in lettura e 50 MB / sec in riscrittura di dati sequenziali da ciascun disco, sulla base dei parametri di riferimento di un analogo disco RED da 4 TB. Mi aspetto non meno di 100 MB / sec in lettura o scrittura, poiché qualsiasi disco può farlo in questi giorni.
5. Ho pensato di vedere un utilizzo IO al 100% su tutti e 4 i dischi quando sotto carico leggevo o scrivevo dati sequenziali. E che i dischi verrebbero distribuiti oltre 100 MB / sec con un utilizzo del 100%.
6. Ho pensato che il pool mi avrebbe dato circa 2x scrivere, 2x riscrivere e 4x leggere le prestazioni su un singolo disco - sbaglio?
7. NOVITÀ Ho pensato che uno zvol ext4 sullo stesso pool avrebbe circa la stessa velocità di ZFS

Quello che effettivamente ottengo

Trovo che le prestazioni di lettura del pool non siano così alte come mi aspettavo

bonnie ++ benchmark sul pool di qualche giorno fa

Versione 1.97 ------ Uscita sequenziale ------ --Ingresso equivalente- - Casuale-
Concorrenza 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Dimensioni macchina K / sec% CP K / sec% CP K / sec% CP K / sec% CP K / sec% CP / sec% CP
igor 63G 99 99 232132 47 118787 27 336 97 257072 22 92,7 6

bonnie ++ su un singolo disco ROSSO da 4 TB da solo in uno zpool

Versione 1.97 ------ Uscita sequenziale ------ --Ingresso equivalente- - Casuale-
Concorrenza 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Dimensioni macchina K / sec% CP K / sec% CP K / sec% CP K / sec% CP K / sec% CP / sec% CP
vigore 63G 101 99 115288 30 49781 14 326 97 138250 13 111,6 8

In base a ciò, le velocità di lettura e riscrittura sono appropriate in base ai risultati di una singola unità RED da 4 TB (sono doppie). Tuttavia, la velocità di lettura che mi aspettavo sarebbe stata di circa 550 MB / sec (4 volte la velocità dell'unità da 4 TB) e almeno spererei per circa 400 MB / sec. Invece sto vedendo circa 260 MB / sec

bonnie ++ sul pool da adesso, mentre raccoglie le informazioni di seguito. Non è più come prima, e nulla è cambiato.

Versione 1.97 ------ Uscita sequenziale ------ --Ingresso equivalente- - Casuale-
Concorrenza 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Dimensioni macchina K / sec% CP K / sec% CP K / sec% CP K / sec% CP K / sec% CP / sec% CP
igor 63G 103 99 207518 43 108810 24 342 98 302350 26 256,4 18

zpool iostat durante la scrittura. Mi sembra a posto.

                                                 larghezza di banda delle operazioni di capacità
pool alloc free read write read write
-------------------------------------------- ----- - ---- ----- ----- ----- -----
pool2 1.23T 2.39T 0 1.89K 1.60K 238M
  specchio 631G 1.20T 0 979 1.60K 120M
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469 - - 0 1007 1.60K 124M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX - - 0 975 0 120M
  specchio 631G 1.20T 0 953 0 117M
    ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536 - - 0 1,01 K 0 128 M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE - - 0 953 0 117M

zpool iostat durante la riscrittura. Mi sembra ok, penso .

                                                 larghezza di banda delle operazioni di capacità
pool alloc free read write read write
-------------------------------------------- ----- - ---- ----- ----- ----- -----
pool2 1,27 T 2,35 T 1015 923 125 M 101 M
  specchio 651G 1.18T 505 465 62.2M 51.8M
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469 - - 198 438 24,4 M 51,7 M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX - - 306384 37,8 M 45,1 M
  specchio 651G 1.18T 510 457 63.2M 49.6M
    ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536 - - 304 371 37,8 M 43,3 M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE - - 206 423 25,5 M 49,6 M

È qui che mi chiedo cosa stia succedendo

zpool iostat durante la lettura

                                                 larghezza di banda delle operazioni di capacità
pool alloc free read write read write
-------------------------------------------- ----- - ---- ----- ----- ----- -----
pool2 1.27T 2.35T 2.68K 32 339M 141K
  specchio 651G 1.18T 1.34K 20 169M 90.0K
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469 - - 748 9 92.5M 96.8K
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX - - 623 10 76,8 M 96,8 K
  specchio 651G 1.18T 1.34K 11 170M 50.8K
    ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536 - - 774 5 95.7M 56.0K
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE - - 599 6 74.0M 56.0K

iostat -x durante la stessa operazione di lettura. Nota come IO% non è al 100%.

Dispositivo: rrqm / s wrqm / sr / sw / s rkB / s wkB / s avgrq-sz avgqu-sz attendono r_await w_await svctm% util
sdb 0,60 0,00 661,30 6,00 83652,80 49,20 250,87 2,32 3,47 3,46 4,87 1,20 79,76
sdd 0,80 0,00 735,40 5,30 93273,20 49,20 251,98 2,60 3,51 3,51 4,15 1,20 89,04
sdf 0,50 0,00 656,70 3,80 83196,80 31,20 252,02 2,23 3,38 3,36 6,63 1,17 77,12
sda 0.70 0.00 738.30 3.30 93572.00 31.20 252.44 2.45 3.33 3.31 7.03 1.14 84.24

zpool e test delle impostazioni del set di dati:

• atime è spento
• la compressione è disattivata
• ashift è 0 (rilevamento automatico - la mia comprensione era che questo era ok)
• zdb dice che i dischi sono tutti ashift = 12
• modulo - opzioni zfs zvol_threads = 32 zfs_arc_max = 17179869184
• sync = standard

Modifica - 30 ottobre 2015

Ho fatto qualche altro test

• set di dati bonnie ++ w / recordsize = 1M = 226 MB in scrittura, 392 MB in lettura molto meglio
• dataset dd w / record size = 1M = 260 MB in scrittura, 392 MB in lettura molto meglio
• zvol w / ext4 dd bs = 1M = 128 MB in scrittura, 107 MB in lettura perché così lento?
• set di dati 2 processori in parallelo = 227 MB in scrittura, 396 MB in lettura
• dd direct io non fa differenza sul set di dati e su zvol

Sono molto più felice della performance con l'aumentata dimensione del disco. Quasi tutti i file nel pool superano di 1 MB. Quindi lo lascerò così. I dischi non ottengono ancora il 100% di utilizzo, il che mi fa chiedere se potrebbe essere ancora molto più veloce. E ora mi chiedo perché la performance di zvol sia così scadente, in quanto è qualcosa che io (leggermente) uso.

Sono felice di fornire tutte le informazioni richieste nei commenti / risposte. Ci sono anche tonnellate di informazioni pubblicate nell'altra mia domanda: copia lenta tra le directory NFS / CIFS sullo stesso server

Sono pienamente consapevole del fatto che potrei non capire qualcosa e che questo potrebbe non essere affatto un problema. Grazie in anticipo.

Per chiarire, la domanda è: perché il pool ZFS non è veloce come mi aspetto? E forse c'è qualcos'altro che non va?

Sono riuscito ad ottenere velocità molto vicine ai numeri che mi aspettavo.

Cercavo 400 MB / sec e gestivo 392 MB / sec . Quindi dico che il problema è stato risolto. Con l'aggiunta successiva di un dispositivo cache, sono riuscito a leggere 458 MB / sec (credo nella cache).

1. Questo inizialmente è stato ottenuto semplicemente aumentando il recordsizevalore del set di dati ZFS a1M

zfs set recordsize=1M pool2/test

Credo che questo cambiamento porti solo a una minore attività del disco, quindi a letture e scritture sincrone di grandi dimensioni più efficienti. Esattamente quello che stavo chiedendo.

Risultati dopo la modifica

• bonnie ++ = 226 MB in scrittura, 392 MB in lettura
• dd = 260 MB in scrittura, 392 MB in lettura
• 2 processi in parallelo = 227 MB in scrittura, 396 MB in lettura

2. Sono riuscito ancora meglio quando ho aggiunto un dispositivo cache (SSD da 120 GB). La scrittura è un po 'più lenta, non sono sicuro del perché.

Version  1.97       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
igor            63G           208325  48 129343  28           458513  35 326.8  16

Il trucco con il dispositivo cache era di impostare l2arc_noprefetch=0in /etc/modprobe.d/zfs.conf . Consente a ZFS di memorizzare nella cache dati streaming / sequenziali. Fallo solo se il tuo dispositivo cache è più veloce del tuo array, come il mio.

Dopo aver beneficiato della modifica del recordset sul mio set di dati, ho pensato che potesse essere un modo simile per gestire le scarse prestazioni di zvol.

Mi sono imbattuto in diverse persone che hanno volblocksize=64kaffermato di aver ottenuto buone prestazioni usando un , quindi l'ho provato. Senza fortuna.

zfs create -b 64k -V 120G pool/volume

Ma poi ho letto che ext4 (il filesystem con cui stavo testando) supporta opzioni come RAID stridee stripe-widthche non avevo mai usato prima. Quindi ho usato questo sito per calcolare le impostazioni necessarie: https://busybox.net/~aldot/mkfs_stride.html e ho formattato di nuovo lo zvol.

mkfs.ext3 -b 4096 -E stride=16,stripe-width=32 /dev/zvol/pool/volume

Ho corso bonnie++per fare un semplice benchmark e i risultati sono stati eccellenti. Purtroppo non ho i risultati con me, ma sono stati almeno 5-6 volte più veloci per le scritture, come ricordo. Aggiornerò di nuovo questa risposta se eseguo nuovamente il benchmark.

I tuoi risultati sono perfettamente ragionevoli, mentre le tue aspettative non lo sono: esageri il miglioramento delle prestazioni di lettura dato da RAID1 (e, per estensione, da RAID10). Il punto è che un mirroring a 2 vie fornisce al massimo 2x la velocità di lettura / IOP del singolo disco, ma le prestazioni del mondo reale possono essere ovunque tra 1x-2x.

Chiariamo con un esempio. Immagina di avere un sistema con mirror a 2 vie, con ogni disco capace di 100 MB / s (sequenziale) e 200 IOPS. Con una profondità della coda pari a 1 (massimo una singola, richiesta in sospeso) questo array non avrà alcun vantaggio su un singolo disco: RAID1 divide le richieste IO sulla coda dei due dischi, ma non divide una singola richiesta su due dischi (almeno, qualsiasi implementazione che ho visto si comporta in questo modo). D'altra parte, se la tua coda di I / O è più grande (ad esempio: hai 4/8 richieste in sospeso), il throughput totale del disco sarà significativamente superiore rispetto al singolo disco.

Un punto simile può essere fatto per RAID0, ma in questo caso ciò che determina i miglioramenti medi è una funzione non solo della dimensione della coda, ma anche della dimensione della richiesta di I / O : se la tua dimensione di I / O media è inferiore alla dimensione del blocco, non verrà barrata su due (o più) dischi, ma sarà servito da uno solo. I risultati ottenuti con l'aumentata dimensione di Bonnie ++ mostrano questo comportamento esatto: lo striping beneficia notevolmente di dimensioni IO maggiori.

Ora dovrebbe essere chiaro che la combinazione dei due livelli RAID in un array RAID10 non porterà a un ridimensionamento lineare delle prestazioni, ma stabilisce un limite superiore per questo. Sono abbastanza sicuro che se esegui più istanze dd / bonnie ++ (o usi fioper manipolare direttamente la coda IO) otterrai risultati più in linea con le tue aspettative originali, semplicemente perché tasserai l'array IO in un modo più completo ( più richieste di I / O sequenziali / casuali estreme), anziché caricarlo solo di singole richieste di I / O sequenziali.