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 di I / O 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é l'MDF (i registri sono memorizzati sul disco locale) né l'unità di backup hanno alcuna attività (IOPS ~ = 0 - abbiamo molta memoria). Lunghezza della coda del disco ~ = 0 pure. La CPU si aggira intorno al 2-3%, nessun problema neanche lì.

La SAN è un Dell MD3220i, il LUN costituito da unità SAS 6x10k. Il server è connesso alla SAN attraverso due percorsi fisici, ciascuno attraverso uno switch separato con connessioni ridondanti alla SAN, per un totale di quattro percorsi, due dei quali attivi in ​​qualsiasi momento. Posso verificare che entrambe le connessioni siano attive tramite il task manager - suddividendo il carico in modo 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 percorsi LUN preferiti è sullo stesso controller 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.

Mostra entrambi i percorsi SAN in uso, quindi in discesa.

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.

Notare un'azione molto piccola on / off, anche se prestazioni straordinarie alla fine.

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:

Aggiornamento - IO bancarelle
ho eseguito la query dm_io_virtual_file_stats di 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 devono colpire il disco - solo una supposizione però .

Aggiornamento: statistiche di attesa
Ho effettuato tre test per raccogliere alcune statistiche di attesa. Le statistiche di attesa vengono interrogate usando lo script Glenn Berry / Paul Randals . 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:

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

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

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 abbiamo più percorsi attivi, ho potuto cambiare la configurazione delle schede di rete in modo relativamente semplice una per una senza causare interruzioni.

La disabilitazione di TOE e Large Send Offload ha prodotto una corsa quasi perfetta:

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:

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

TOE disabilitato, LSO abilitato - aspetto gradevole:

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:

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 il motore offload TCP di Broadcom NIC abilitato abbia causato i problemi. Non appena TOE è stato disabilitato, tutto ha funzionato come un fascino. 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 presentare richieste IO sospese. Questo server non eseguiva SQL Server, ma semplicemente Windows Web Server 2008 R2 che serviva condivisioni su CIFS. Non appena 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.

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 un'altra scheda di rete 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 potrebbe essere necessario disabilitare le funzionalità a livello di driver della scheda in alcune circostanze, di certo non farà male farlo.

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 usata 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.