Ottimizzazione dello scrubbing ZFS, 141 KB / s in esecuzione per 15 giorni

14

Un sistema piuttosto semplice che esegue mirror + stripe su dischi sas a 7,2k rpm, non particolarmente caricati. Nessuna deduplicazione, compressione su tutti i set di dati. Scrub ha funzionato per 15 giorni alla velocità di una lumaca morta. C'è qualche ottimizzazione che deve essere fatta o può essere dovuta a qualche errore?

  • Dell R510 con custodia MD1200.
  • 2x Xeon E5620
  • 48GB
  • NexentaStor 3.1.3, edizione comunitaria

Alcune informazioni:

scan: scrub in progress since Mon Apr  1 19:00:05 2013
171G scanned out of 747G at 141K/s, 1187h40m to go
0 repaired, 22.84% done
config:

    NAME                       STATE     READ WRITE CKSUM
    tank                       ONLINE       0     0     0
      mirror-0                 ONLINE       0     0     0
        c7t5000C500414FB2CFd0  ONLINE       0     0     0
        c7t5000C500414FCA57d0  ONLINE       0     0     0
      mirror-1                 ONLINE       0     0     0
        c7t5000C500415C3B1Bd0  ONLINE       0     0     0
        c7t5000C500415C5E4Fd0  ONLINE       0     0     0
      mirror-2                 ONLINE       0     0     0
        c7t5000C500415DC797d0  ONLINE       0     0     0
        c7t5000C500415DC933d0  ONLINE       0     0     0
    logs
      c7t5000A7203006D81Ed0    ONLINE       0     0     0
    cache
      c7t5000A72030068545d0    ONLINE       0     0     0


# iostat -en     
---- errors --- 
s/w h/w trn tot device
0 8887   0 8887 c2t0d0
0   0   0   0 c0t395301D6B0C8069Ad0
0   0   0   0 c7t5000C500415DC933d0
0   0   0   0 c7t5000A72030068545d0
0   0   0   0 c7t5000C500415DC797d0
0   0   0   0 c7t5000C500414FCA57d0
0   0   0   0 c7t5000C500415C3B1Bd0
0   0   0   0 c7t5000C500415C5E4Fd0
0   0   0   0 c7t5000C500414FB2CFd0
0   0   0   0 c7t5000A7203006D81Ed0

Spa_last_io viene cambiato ogni volta che eseguo questo

# echo "::walk spa | ::print spa_t spa_name spa_last_io spa_scrub_inflight" | mdb -k
spa_name = [ "syspool" ]
spa_last_io = 0x25661402
spa_scrub_inflight = 0
spa_name = [ "tank" ]
spa_last_io = 0x25661f84
spa_scrub_inflight = 0x21

Ogni 5 secondi, vengono scritti circa 20-25 MB / s. Tra quelle scritture non ci sono praticamente letture o scritture.

                          capacity     operations    bandwidth      latency
    pool                       alloc   free   read  write   read  write   read  write
    -------------------------  -----  -----  -----  -----  -----  -----  -----  -----
    syspool                     427G   501G      0      0      0      0   0.00   0.00
      c0t395301D6B0C8069Ad0s0   427G   501G      0      0      0      0   0.00   0.00
    -------------------------  -----  -----  -----  -----  -----  -----  -----  -----
    tank                        903G  1.84T    810  5.21K  1.50M  20.8M   9.42   4.71
      mirror                    301G   627G     22  1.00K  53.0K  3.96M   8.96   3.93
        c7t5000C500414FB2CFd0      -      -     20    244  50.1K  3.97M   6.70   1.14
        c7t5000C500414FCA57d0      -      -     19    242  48.2K  3.97M   7.60   1.12
      mirror                    301G   627G     25   1016  46.8K  4.10M  16.11   5.28
        c7t5000C500415C3B1Bd0      -      -     21    257  41.6K  4.11M   4.63   1.24
        c7t5000C500415C5E4Fd0      -      -     21    255  43.0K  4.11M  16.54   1.15
      mirror                    301G   627G     62    754   119K  3.03M  19.72   3.78
        c7t5000C500415DC797d0      -      -     57    219   114K  3.03M   9.99   1.15
        c7t5000C500415DC933d0      -      -     56    220   119K  3.03M  13.20   1.22
      c7t5000A7203006D81Ed0     260K  46.5G      0      0      0      0   0.00   0.00
    cache                          -      -      -      -      -      -
      c7t5000A72030068545d0    93.1G     8M      0      0      0      0   0.00   0.00
    -------------------------  -----  -----  -----  -----  -----  -----  -----  -----

Gli iostati mi stanno dicendo che sto trascorrendo più tempo ad aspettare il disco di quanto dovrei? In particolare la colonna% b

# iostat -xe
device    r/s    w/s   kr/s   kw/s wait actv  svc_t  %w  %b s/w h/w trn tot 
sd3       5.1   43.9   20.6  643.8  0.0  0.1    2.9   0   5   0   0   0   0 
sd4       9.4    1.8  141.1  169.6  0.0  0.0    0.5   0   0   0   0   0   0 
sd5       3.1   43.8   15.8  643.8  0.0  0.1    1.4   0   3   0   0   0   0 
sd6       5.2   38.1   14.3  494.4  0.0  0.1    3.0   0   7   0   0   0   0 
sd7       4.2   40.2   11.1  623.2  0.0  0.1    2.7   0   7   0   0   0   0 
sd8       3.6   44.3    9.7  623.2  0.0  0.1    1.5   0   4   0   0   0   0 
sd9       2.9   37.4    7.0  494.4  0.0  0.1    1.3   0   2   0   0   0   0 
sd10      0.7    0.4    3.4    0.0  0.0  0.0    0.0   0   0   0   0   0   0

La latenza è un po 'alta?

# zpool iostat 10 10
               capacity     operations    bandwidth      latency
pool        alloc   free   read  write   read  write   read  write
tank         909G  1.83T     86  2.82K   208K  12.7M  22.68  13.63
----------  -----  -----  -----  -----  -----  -----  -----  -----
tank         909G  1.83T     29    857  42.4K  3.50M  17.86   4.47
----------  -----  -----  -----  -----  -----  -----  -----  -----
tank         909G  1.83T     30    947  46.1K  3.54M  15.55   5.67

Applicato alcune modifiche che hanno fatto poca differenza. zfs_top_maxinflight impostato su 127, zfs_scrub_delay su 0 e zfs_scan_idle su 0.

# echo zfs_top_maxinflight | mdb -k
zfs_top_maxinflight:
zfs_top_maxinflight:            127

# echo zfs_scrub_delay/D |mdb -k
zfs_scrub_delay:
zfs_scrub_delay:0

# echo zfs_scan_idle/D |mdb -k
zfs_scan_idle:
zfs_scan_idle:  0


 scan: scrub in progress since Wed Apr 17 20:47:23 2013
    1.85G scanned out of 918G at 1.14M/s, 229h36m to go
    0 repaired, 0.20% done

pre mdb tweak, nota la colonna b% piuttosto alta

$ iostat -nx -M 5 

  r/s    w/s   Mr/s   Mw/s wait actv wsvc_t asvc_t  %w  %b device
  0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c2t0d0
  0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c0t395301D6B0C8069Ad0
 35.2   44.2    0.3    0.7  0.0  0.4    0.0    5.3   0  32 c7t5000C500415DC933d0
 19.8    3.2    0.2    0.0  0.0  0.0    0.0    0.1   0   0 c7t5000A72030068545d0
 31.2   46.2    0.2    0.7  0.0  0.3    0.0    4.4   0  27 c7t5000C500415DC797d0
 30.6   46.8    0.2    0.8  0.0  0.4    0.0    4.6   0  28 c7t5000C500414FCA57d0
 37.6   53.0    0.3    0.8  0.0  0.4    0.0    4.7   0  33 c7t5000C500415C3B1Bd0
 37.6   53.6    0.3    0.8  0.0  0.5    0.0    5.6   0  39 c7t5000C500415C5E4Fd0
 33.2   46.8    0.3    0.8  0.0  0.5    0.0    6.1   0  33 c7t5000C500414FB2CFd0
  0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c7t5000A7203006D81Ed0

post tweak mdb, nota la colonna b%, 80-85% tempo in attesa di occupato

$ iostat -nx -M 5 
  r/s    w/s   Mr/s   Mw/s wait actv wsvc_t asvc_t  %w  %b device
  0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c2t0d0
  0.2   27.2    0.0    0.3  0.0  1.0    0.0   35.4   0  18 c0t395301D6B0C8069Ad0
129.6   20.2    0.9    0.4  0.0  2.9    0.0   19.5   0  85 c7t5000C500415DC933d0
 48.4    4.0    0.4    0.0  0.0  0.0    0.0    0.1   0   1 c7t5000A72030068545d0
130.4   19.8    0.9    0.4  0.0  3.0    0.0   20.2   0  84 c7t5000C500415DC797d0
125.8   25.8    0.9    0.5  0.0  2.9    0.0   19.2   0  80 c7t5000C500414FCA57d0
131.2   24.2    0.9    0.5  0.0  3.1    0.0   20.3   0  83 c7t5000C500415C3B1Bd0
130.6   25.8    0.9    0.5  0.0  3.5    0.0   22.5   0  88 c7t5000C500415C5E4Fd0
126.8   28.0    0.9    0.5  0.0  2.8    0.0   18.0   0  79 c7t5000C500414FB2CFd0
  0.2    0.0    0.0    0.0  0.0  0.0    0.0    0.1   0   0 c7t5000A7203006D81Ed0
zfs  nexenta 
— 3molo
fonte
Quale ricorrenza multipla di iostat -XnE | errori grep dice? alcuni errori contano l'incremento?
Zero in tutte le colonne
— 3molo
Cosa smartctl -A /dev/diskdice di ogni unità (potrebbe essere necessario installarlo smartctl, non sono sicuro se viene fornito con l'installazione di base).
— Chris S,
1
Nulla di interessante, oltre a "Conteggio errori non medi: 8071" su un disco. Tutti i dischi si trovano in un JBOD (Dell MD1200) sulla stessa (singola) sas lane
— 3molo

Risposte:

11

Le operazioni di scrub ZFS operano su alcuni principi abbastanza cerebrali. In particolare, passa solo il tempo a strofinare quando non succede nient'altro. Se colpisci un pool con un po 'di accesso ai dati su una base abbastanza costante, scrub morirà di fame e non farà quasi nulla.

Sintonizzabili da esplorare, con le mie brevi note su ciò che fa (ho esaminato l'ultima volta questo tempo fa, però):

  • zfs_scan_idle - se l'I / O utente si verifica in questo numero di tick di clock, ritarda scrub I / O di zfs_scrub_delay tick di clock
  • zfs_scrub_delay - quanti tick di clock ritardano l'operazione di scrub se attivato da zfs_scan_idle
  • zfs_top_maxinflight - numero massimo di I / O scrub per vdev di livello superiore
  • zfs_scrub_limit - numero massimo di I / O scrub per foglia vdev
  • zfs_scan_min_time_ms - ms minimo da spendere per txg in operazioni di pulizia
  • zfs_no_scrub_io - nessuna nota
  • zfs_no_scrub_prefetch - nessuna nota, il nome sembra implicare non causare prefetch su scrub ops

Tutti questi sono modificabili al volo usando "echo [sintonizzabile] / W0t [numero]" per cambiare e "echo [sintonizzabile / D" per visualizzare le impostazioni correnti (cosa che consiglio di fare prima di cambiare).

Quindi, in teoria, e in pratica, se dovessi, per esempio, cambiare zfs_scan_idle in 10 (o 1 - o 0, se lo supporta, devi controllare il codice) e zfs_scrub_delay in 1 (o 0, se lo supporta), e se la tua impostazione txg_synctime_ms è 5000 o più, potresti cambiare un po 'zfs_scan_min_time_ms, dovrebbe diventare molto più aggressivo nel fare effettivamente operazioni di scrub anche con un certo livello di I / O dell'utente.

Nel tuo caso specifico,% b e asvc_t segnalati implicano un carico di lavoro di lettura molto, molto casuale in corso (i dischi rotanti dovrebbero fare di meglio se è veramente sequenziale) e hai già fatto le cose "facili" come spiegato sopra . Quindi, per prima cosa accenderei zfs_no_scrub_prefetch, per disabilitare il prefetch sulle operazioni di scrub, solo per vedere se questo ha aiutato. Se non c'è gioia, a seconda della versione di Nexenta in uso, potresti eseguire 30/5, 5/1 o 10/5 (che è la scorciatoia che usiamo per le impostazioni di zfs_txg_timeout & (zfs_txg_synctime_ms * 1000)). Cambia zfs_txg_timeout su 10 e zfs_txg_synctime_ms su 5000, quindi prova ad aumentare zfs_scan_min_time_ms su 3000 o 4000. Questo dice a ZFS che può spendere molto più tempo su scrub, rispetto alle impostazioni predefinite su vecchie installazioni NexentaStor che usano 5/1 come impostazioni predefinite - ma attento,

Spero che sia di aiuto. In bocca al lupo!

— NEX7
fonte
Suppongo che dovrei notare che modificate queste impostazioni in bash usando "echo <tunable> / W0t <number> | mdb -kw". E vedi i valori correnti con "echo <tunable> / D | mdb -k". Le mie note dicono che tutte queste possono essere cambiate in volo, nessuna sembra richiedere una modifica del sistema / etc / e riavviare per avere effetto.
— Nex7,
Dovrei anche leggere l'intera domanda prima di rispondere e interrompere la navigazione su ServerFault durante le chiamate in conferenza. :)
— Nex7
% B e asvc_t segnalati implicano un carico di lavoro di lettura molto, molto casuale in corso (i dischi rotanti dovrebbero fare meglio di così se sono veramente sequenziali). Per prima cosa accenderei zfs_no_scrub_prefetch, per disabilitare il prefetch sulle operazioni di scrub, solo per vedere se questo ha aiutato. In caso contrario, a seconda della versione di Nexenta in uso, potresti eseguire 30/5, 5/1 o 10/5 (zfs_txg_timeout & (zfs_txg_synctime_ms * 1000). Modifica zfs_txg_timeout su 10 e zfs_txg_synctime_ms su 5000, quindi prova aumentando zfs_scan_min_time_ms a 3000 o 4000. Questo dice a ZFS che può spendere molto più tempo su scrub, può morire di fame I / O normale!
— Nex7
Penso che tu possa fornire input molto preziosi, ma sarebbe molto più utile se tu potessi aggiungere i commenti in una buona risposta.
— 3molo,
2
Una maggiore messa a punto potrebbe aver aiutato, ma non necessariamente. È importante notare che uno scrub ZFS scorre attraverso la struttura dei dati, NON settore per settore sui dischi. Vale a dire, a seconda di come la struttura dei dati di zfs appare sui tuoi dischi, un'operazione di pulizia può sembrare incredibilmente casuale - i tuoi dischi potrebbero essere in grado di> 100 MB / s di lettura sequenziale , ma la lettura completamente casuale sarà un'altra storia interamente . Anche la dimensione media del blocco sarebbe importante qui.
— Nex7,
3

Ho il sospetto che l'hardware ...

Perché dovresti lasciarlo funzionare per 15 giorni? Non è normale Ferma lo scrub - zpool scrub -s tanke controlla il sistema.

  • Quali controller stai usando?
  • È questo il primo scrub che hai mai eseguito su questo pool?
  • C'è stato un problema che ti ha spinto a eseguire lo scrub in primo luogo?
— ewwhite
fonte
1
LSI SAS9200-8e (firmware IT). Non primo scrub. No, nessun problema reale (ma ho messo in dubbio le prestazioni sequenziali di lettura / scrittura per un po ').
— 3molo,
Aggiornato con latenza e tempi di attesa, iniziando a sospettare che ci sia sempre un po 'di tempo per soddisfare le richieste e che dà priorità allo scrub così basso che si ferma. Qualsiasi intuizione è molto utile!
— 3molo,
Gli scrub sono importanti da eseguire periodicamente. Attendere fino a quando non si riscontra un problema con l'esecuzione di uno scrub richiede che il problema esploda nella perdita di dati. Scrub sono lì per catturare la corruzione silenziosa dei dati (bitrot). Uno scrub a esecuzione lenta non è un segno di un problema di sistema, ma solo un pool tenuto abbastanza occupato da non consentire l'accelerazione dello scrub.
— lschweiss,
0

La mia risposta arriva un po 'in ritardo, ma se questo genere di cose succede a qualcun altro, ecco la mia opinione: provate semplicemente "dmesg". Nel mio caso, non stavo facendo uno scrub, ma stavo copiando i file sui dischi e sentivo chiaramente che i dischi erano attivi per alcuni secondi, poi si sono fermati per un tempo più lungo, e di nuovo hanno funzionato e così via. Ciò era dovuto al fallimento di un controller SATA e dmesg mi ha dato tutti gli errori. All'inizio ho pensato che fosse un disco guasto, ma poi ho capito che in realtà era il controller.

— jytou
fonte
-3

Scrub utilizza i tempi di inattività del sistema disponibili, anche su un server senza carico, riguarda la disponibilità. Ram e processore sono le chiavi per cancellare l'utilizzo, non il disco. Più di questi sono disponibili, migliore sarà la tua prestazione di pulizia. Tuttavia, certamente, in questo caso, migliore è la disposizione dei tuoi dischi, in termini di ZPools, migliore sarà anche la tua performance di scrub.

Quindi, se la tua performance è stata lenta e questo sembra essere il caso, considererei questi come potenziali motivi.

— user169761
fonte
1
Non vedo alcun indicatore che le risorse siano scarse.
— 3molo,
1
Questo è praticamente completamente falso. CPU e RAM hanno effettivamente un impatto pari a zero sulle operazioni di pulizia (supponendo che ci sia del tutto gratuito). Avere molta RAM e CPU libere non accelererà le operazioni di pulizia. Scrub è limitato osservando l'I / O in entrata nel pool, non controllando i "tempi di inattività del sistema disponibili", qualunque cosa sia.
— Nex7,
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.