it-swarm.it

Le richieste di I / O richiedono più di 15 secondi

Di solito i nostri backup completi settimanali terminano in circa 35 minuti, con backup differenziali giornalieri che terminano in ~ 5 minuti. Da martedì i quotidiani hanno impiegato quasi 4 ore per completare, molto più di quanto dovrebbe essere richiesto. Per coincidenza, questo ha iniziato ad accadere subito dopo aver ottenuto una nuova configurazione SAN/disco.

Si noti che il server è in esecuzione in produzione e non abbiamo problemi generali, funziona senza problemi, ad eccezione del problema IO che si è manifestato principalmente nelle prestazioni di backup.

Osservando dm_exec_requests durante il backup, il backup è costantemente in attesa su ASYNC_IO_COMPLETION. Ah, quindi abbiamo contesa sul disco!

Tuttavia, né il MDF (i log sono memorizzati sul disco locale) né l'unità di backup hanno alcuna attività (IOPS ~ = 0 - abbiamo molta memoria). Lunghezza della coda del disco ~ = 0. La CPU si aggira intorno al 2-3%, nessun problema neanche lì.

Il SAN è un Dell MD3220i, il LUN costituito da 6x10k SAS. Il server è collegato al SAN tramite due percorsi fisici, ognuno dei quali passa attraverso uno switch separato con connessioni ridondanti al SAN - un totale di quattro percorsi, due dei quali sono attivi in ​​qualsiasi momento. Posso verificare che entrambe le connessioni siano attive tramite task manager - suddivisione del carico perfettamente uniforme: entrambe le connessioni eseguono 1G full duplex.

Usavamo i jumbo frame, ma li ho disabilitati per escludere qualsiasi problema qui - nessuna modifica. Abbiamo un altro server (stesso sistema operativo + configurazione, 2008 R2) che è collegato ad altri LUN e non mostra alcun problema. Tuttavia, non esegue SQL Server, ma condivide semplicemente CIFS. Tuttavia, uno dei suoi percorsi LUN preferiti è sullo stesso SAN dei LUN problematici - quindi l'ho escluso anch'io.

L'esecuzione di un paio di test SQLIO (file di test 10G) sembra indicare che IO è decente, nonostante i problemi:

sqlio -kR -t8 -o8 -s30 -frandom -b8 -BN -LS -Fparam.txt
IOs/sec:  3582.20
MBs/sec:    27.98
Min_Latency(ms): 0
Avg_Latency(ms): 3
Max_Latency(ms): 98
histogram:
ms: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%: 45  9  5  4  4  4  4  4  4  3  2  2  1  1  1  1  1  1  1  0  0  0  0  0  2

sqlio -kW -t8 -o8 -s30 -frandom -b8 -BN -LS -Fparam.txt
IOs/sec:  4742.16
MBs/sec:    37.04
Min_Latency(ms): 0
Avg_Latency(ms): 2
Max_Latency(ms): 880
histogram:
ms: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%: 46 33  2  2  2  2  2  2  2  1  1  1  1  0  0  0  0  0  0  0  0  0  0  0  1

sqlio -kR -t8 -o8 -s30 -fsequential -b64 -BN -LS -Fparam.txt
IOs/sec:  1824.60
MBs/sec:   114.03
Min_Latency(ms): 0
Avg_Latency(ms): 8
Max_Latency(ms): 421
histogram:
ms: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%:  1  3 14  4 14 43  4  2  1  1  1  1  1  1  0  0  0  0  0  0  0  0  0  0  6

sqlio -kW -t8 -o8 -s30 -fsequential -b64 -BN -LS -Fparam.txt
IOs/sec:  3238.88
MBs/sec:   202.43
Min_Latency(ms): 1
Avg_Latency(ms): 4
Max_Latency(ms): 62
histogram:
ms: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%:  0  0  0  9 51 31  6  1  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0

Mi rendo conto che questi non sono test esaustivi in ​​alcun modo, ma mi fanno sentire a mio agio nel sapere che non è spazzatura completa. Si noti che le prestazioni di scrittura più elevate sono causate dai due percorsi MPIO attivi, mentre la lettura ne utilizzerà solo uno.

Il controllo del registro eventi dell'applicazione rivela eventi come questi sparsi:

SQL Server has encountered 2 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [J:\XXX.mdf] in database [XXX] (150).  The OS file handle is 0x0000000000003294.  The offset of the latest long I/O is: 0x00000033da0000

Non sono costanti, ma accadono regolarmente (un paio all'ora, più durante i backup). Accanto a quell'evento, il registro eventi di sistema pubblicherà questi:

Initiator sent a task management command to reset the target. The target name is given in the dump data.
Target did not respond in time for a SCSI request. The CDB is given in the dump data.

Questi si verificano anche sul server CIFS non problematico in esecuzione sullo stesso SAN/Controller e dal mio Google sembrano essere non critici.

Si noti che tutti i server utilizzano le stesse schede NIC - Broadcom 5709C con driver aggiornati. I server stessi sono Dell R610.

Non sono sicuro di cosa controllare per il prossimo. Eventuali suggerimenti?

Aggiornamento - Esecuzione di perfmon
Ho provato a registrare il Avg. Secondi disco/Lettura e scrittura contatori perf durante l'esecuzione di un backup. Il backup inizia in modo strabiliante, quindi sostanzialmente si interrompe al 50%, trascinandosi lentamente verso il 100%, ma impiegando 20 volte il tempo che avrebbe dovuto.

Task monitor during start of backup Mostra entrambi SAN percorsi utilizzati, quindi in calo.

Perform during same Il backup è iniziato alle 15:38:50 - notate che tutto sembra buono, e poi c'è una serie di picchi. Non mi preoccupo delle scritture, solo le letture sembrano bloccarsi.

Task monitor during end of backup Notare un'azione molto piccola on/off, anche se prestazioni straordinarie alla fine.

Perfmon during same Nota un massimo di 12 secondi, sebbene la media sia nel complesso buona.

Aggiornamento: backup su dispositivo NUL
Per isolare i problemi di lettura e semplificare le cose, ho eseguito quanto segue:

BACKUP DATABASE XXX TO DISK = 'NUL'

I risultati sono stati esattamente gli stessi - inizia con una lettura a raffica e poi si blocca, riprendendo le operazioni di tanto in tanto:

Results

Aggiornamento - IO bancarelle
Ho eseguito la query dm_io_virtual_file_stats da Jonathan Kehayias e Ted Kruegers libro (pagina 29), come raccomandato da Shawn. Guardando i primi 25 file (un file di dati ciascuno - tutti i risultati sono file di dati), sembrerebbe che le letture siano peggiori delle scritture - forse perché le scritture vanno direttamente nella cache SAN mentre le letture fredde deve colpire il disco - solo una supposizione però.

IO Stalls

Aggiornamento - Attendi statistiche
Ho fatto tre prove per raccogliere alcune statistiche di attesa. Le statistiche di attesa vengono interrogate utilizzando Glenn Berry/Paul Randals script . E solo per confermare: i backup non vengono eseguiti su nastro, ma su un LUN iSCSI. I risultati sono simili se eseguiti sul disco locale, con risultati simili al backup NUL.

Statistiche cancellate. Ha funzionato per 10 minuti, carico normale: No backup

Statistiche cancellate. Ha funzionato per 10 minuti, carico normale + backup normale in esecuzione (non completato): Normal backup

Statistiche cancellate. Ha funzionato per 10 minuti, carico normale + backup NUL in esecuzione (non completato): NUL backup

Aggiornamento - Wtf, Broadcom?
Sulla base dei suggerimenti di Mark Storey-Smiths e delle precedenti esperienze di Kyle Brandts con le schede di rete Broadcom, ho deciso di fare qualche sperimentazione. Dato che disponiamo di più percorsi attivi, potrei cambiare relativamente facilmente la configurazione delle schede di rete una per una senza causare interruzioni.

La disabilitazione di TOE e Large Send Offload ha prodotto una corsa quasi perfetta: enter image description here

Processed 1064672 pages for database 'XXX', file 'XXX' on file 1.
Processed 21 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064693 pages in 58.533 seconds (142.106 MB/sec).

Quindi qual è il colpevole, TOE o LSO? TOE abilitato, LSO disabilitato: enter image description here

Didn't finish the backup as it took forever - just as the original problem!

TOE disabilitato, LSO abilitato - aspetto gradevole: enter image description here

Processed 1064680 pages for database 'XXX', file 'XXX' on file 1.
Processed 29 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064709 pages in 59.073 seconds (140.809 MB/sec).

E come controllo, ho disabilitato TOE e LSO per confermare che il problema era scomparso: enter image description here

Processed 1064720 pages for database 'XXX', file 'XXX' on file 1.
Processed 13 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064733 pages in 60.675 seconds (137.094 MB/sec).

In conclusione sembra che le schede di rete Broadcom abilitate TCP Offload Engine abbia causato i problemi. Non appena TOE è stato disabilitato, tutto ha funzionato come un incantesimo. Immagino che non ordinerò più NIC Broadcom in futuro .

Aggiornamento: il server CIFS viene disattivato
Oggi il server CIFS identico e funzionante ha iniziato a mostrare IO richieste bloccate. Questo server non stava eseguendo SQL Server, ma semplicemente Windows Web Server 2008 R2 che serviva condivisioni su CIFS. poiché ho disabilitato TOE anche su di esso, tutto è tornato a funzionare senza problemi.

Conferma semplicemente che non userò mai più TOE su NIC Broadcom, se non posso assolutamente evitare le NIC Broadcom.

31

Si noti che tutti i server utilizzano le stesse schede NIC - Broadcom 5709C con driver aggiornati. I server stessi sono Dell R610.

Kyle Brandt ha un'opinione sulle schede di rete Broadcom che fa eco alla mia esperienza (ripetuta).

Broadcom, Die Mutha

I miei problemi sono sempre stati associati alle funzionalità TCP Offload e nel 99% dei casi la disabilitazione o il passaggio a una scheda di rete a-n-altra ha risolto i sintomi. Un client che (come nel tuo caso) utilizza server Dell, ordina sempre schede NIC Intel separate e disabilita le schede Broadcom integrate durante la creazione.

Come descritto in questo post sul blog MSDN , vorrei iniziare con la disabilitazione nel sistema operativo con:

netsh int ip set chimney DISABLED

IIRC in alcune circostanze potrebbe essere necessario disabilitare le funzionalità a livello del driver della scheda, di certo non farà male farlo.

14

Non che io sia un esperto di SAN/disk (ci sono persone qui che ne sanno più di me) ... Condivido solo quello che ho fatto un po 'e leggo principalmente :)

Jonathan Kehayias e Ted Krueger hanno scritto un libro "Risoluzione dei problemi di SQL Server" che contiene alcune informazioni utili sulle prestazioni del disco. Puoi ottenere il PDF gratuitamente da qui . (Potrei comprare anche l'edizione stampata di questo per la mia scrivania.)

Ad ogni modo hanno una buona query che può essere utilizzata per controllare sys.dm_io_virtual_file_stats e controllare la latenza media nei file di dati. Potresti scoprire che RAID10 non è la configurazione ideale per i file di dati su cui risiedere.

4
user507