SQL Server ha riscontrato occorrenze di richieste I / O che richiedono più di 15 secondi

Su Production SQL Server, abbiamo la seguente configurazione:

3 server Dell PowerEdge R630, combinati nel gruppo di disponibilità Tutti e 3 sono collegati a un'unica unità di archiviazione SAN Dell che è un array RAID

Di tanto in tanto, su PRIMARY vediamo messaggi simili ai seguenti:

SQL Server ha riscontrato 11 occorrenze di richieste I / O che richiedono più di 15 secondi per il completamento sul file [F: \ Data \ MyDatabase.mdf] nell'ID database 8.
L'handle del file del sistema operativo è 0x000000000000001FBC.
L'offset dell'ultimo I / O lungo è: 0x000004295d0000.
La durata dell'I / O lungo è: 37397 ms.

Siamo alle prime armi nella risoluzione dei problemi relativi alle prestazioni

Quali sono i modi più comuni o le migliori pratiche per risolvere questo particolare problema relativo all'archiviazione? Quali contatori delle prestazioni, strumenti, monitor, app, ecc. Devono essere usati per restringere la causa principale di tali messaggi? Potrebbe esserci un evento esteso che può aiutare o qualche tipo di audit / registrazione?

Abbiamo una configurazione simile e recentemente abbiamo riscontrato questi messaggi nei registri. Stiamo utilizzando una SAN Compellent DELL. Ecco alcune cose da verificare quando si ricevono questi messaggi che ci hanno aiutato a trovare una soluzione

• Esamina i contatori delle prestazioni di Windows per i dischi a cui puntano i messaggi di avviso, in particolare:
  • Disk avg. Tempo per leggere
  • Disk avg. tempo di scrittura
  • Byte di lettura disco / sec
  • Byte di scrittura su disco / sec
  • Trasferimenti disco / sec
  • Avg. lunghezza della coda del disco
• Quanto sopra sono medie. Se si dispone di molti file di database su un'unità, queste medie possono distorcere il risultato e mascherare un collo di bottiglia su file di database specifici. Dai un'occhiata a questa query di Paul S. Randal che restituisce la latenza media per ogni file dal dmv sys.dm_io_virtual_file_stats. Nel nostro caso la latenza media riportata era accettabile, ma sotto le copertine c'erano molti file con una latenza media> 200 ms.
• Controlla i tempi. C'è qualche modello? Succede più frequentemente a certe ore della notte? In tal caso, verificare se in quel momento sono in esecuzione lavori di manutenzione o attività programmate che potrebbero aumentare l'attività del disco ed esporre un collo di bottiglia nel sottosistema IO.
• Controlla il visualizzatore eventi di Windows per errori. Se il tuo switch o SAN è sovraccarico o non è configurato correttamente per la tua applicazione, potresti trovare alcuni messaggi in questo registro ed è bene portare queste informazioni al tuo amministratore SAN. Nel nostro caso abbiamo ricevuto errori di connessione iSCSI spesso durante il giorno, suggerendo il problema.
• Rivedi il tuo codice SQL Server. Quando ricevi questi messaggi non dovresti immediatamente pensare che si tratti di un problema di sottosistema IO e passarlo al tuo amministratore SAN. Devi fare la tua parte e rivedere il database. Hai delle domande davvero brutte che vengono eseguite sfornando tonnellate di dati? Indicizzazione errata? Scrive un registro delle transazioni eccessivo? È possibile utilizzare alcune query open source per ottenere un controllo dello stato del database, un esempio per verificare l'aspetto del piano di query è sp_blitzCache
• Non ignorarli. Oggi potresti riceverli alcune volte al giorno ... poi diversi mesi dopo, quando il tuo carico di lavoro aumenta e ti sei dimenticato di monitorarli, iniziano ad aumentare. La ricezione di molti di questi messaggi può impedire a SQL Server di accedere a un determinato file e, se è tempdb , non va bene. Nel nostro caso è diventato così male che SQL Server si è chiuso da solo.

La nostra soluzione stava aggiornando il nostro switch a uno switch SAN. Sì, questi sono tutti punti da trattare in SQL Server. Ciò che ci ha portato a scoprire che è stato lo switch che ogni giorno abbiamo ricevuto circa 1500 errori di disconnessione pdu iSCSI nel Visualizzatore eventi di applicazioni Windows su SQL Server. Ciò ha spinto l'indagine da parte dei nostri amministratori SAN sullo switch.

Immediatamente dopo l'aggiornamento, gli errori iSCSI sono scomparsi e la latenza media è scesa a circa 50 ms per tutti i file, e ciò è correlato a migliori prestazioni nell'applicazione. Con questi punti in mente, spero che tu possa trovare la tua soluzione.

Questo è molto meno spesso un problema del disco e molto più spesso un problema di rete. Sai, la N in SAN?

Se vai nel tuo team SAN e inizi a parlare che i dischi sono lenti, ti mostreranno un grafico elaborato con 0 millisecondi di latenza su di esso e quindi indicheranno una cucitrice.

Invece, chiedi loro il percorso di rete verso la SAN. Ottieni velocità, se è multipath, ecc. Ottieni numeri da loro sulle velocità che dovresti vedere. Chiedere se hanno benchmark da quando i server sono stati impostati.

Quindi è possibile utilizzare Crystal Disk Mark o diskpd per convalidare tali velocità. Se non si allineano, di nuovo, è molto probabilmente il networking.

È inoltre necessario cercare nel registro degli errori i messaggi che contengono "FlushCache" e "saturazione", poiché possono anche essere segni di contesa di rete.

Una cosa che puoi fare per evitare quelle cose come un DBA è assicurarti che la tua manutenzione e qualsiasi altra attività pesante di dati (come ETL) non stiano svolgendo contemporaneamente. Ciò può sicuramente esercitare molta pressione sulla rete di archiviazione.

Puoi anche controllare le risposte qui per ulteriori suggerimenti: Checkpoint lento e avvisi I / O di 15 secondi sulla memoria flash

Ho scritto un blog su un argomento simile qui: dal server alla SAN

Perché archiviare i dati su una SAN? Qual e il punto? Tutte le prestazioni del database sono legate all'I / O del disco e si stanno utilizzando 3 server con un solo dispositivo per l'I / O dietro di essi. Non ha senso ... e purtroppo è così comune.

Trascorro la vita incontrando piattaforme hardware mal progettate in cui le persone cercano solo di progettare un computer su larga scala. Tutta la potenza della CPU qui, tutti i dischi lì ... speriamo che non ci sia qualcosa come la RAM remota. E il più triste è che compensano la mancanza di efficienza di questo design con enormi server che costano dieci volte di più di quanto dovrebbero. Ho visto $ 400k più lentamente di un laptop da $ 1k.

Un software SQL Server è un software molto avanzato, progettato per sfruttare qualsiasi componente hardware, core della CPU, cache della CPU, TLB, RAM, controller del disco, cache del disco rigido ... Includono quasi tutta la logica del filesystem. Sono sviluppati su computer regolari e confrontati su sistemi di fascia alta. Pertanto un server SQL deve avere i propri dischi. Installarli su una SAN è come "emulare" un computer, perdi tutte le ottimizzazioni delle prestazioni. Le SAN servono per l'archiviazione di backup, file immutabili e file ai quali si aggiungono solo i dati (registri).

Gli amministratori di Datacenter tendono a mettere tutto ciò che possono sulle SAN perché in questo modo hanno un solo pool di archiviazione da gestire, è più facile che occuparsi dell'archiviazione su ciascun server. È una scelta "Non voglio fare il mio lavoro", e una pessima scelta, perché poi devono affrontare i problemi di prestazioni e tutta la compagnia ne soffre. Installa il software sull'hardware per cui è progettato. Mantienilo semplice. Cura dell'ampiezza di banda I / O, dell'overhead del cambio di contesto e della cache, del jitter di risorse (si verifica quando la risorsa di risorse è condivisa). Finirai per mantenere 1/10 dei dispositivi con la stessa potenza di output non elaborata, risparmi al tuo team operativo molti mal di testa, ottieni prestazioni che rendono felici e produttivi gli utenti finali, rendono la tua azienda un posto migliore in cui lavorare e risparmia molta energia (il pianeta ti ringrazierà).

Hai detto nei commenti, stai pensando di inserire SSD nel tuo server. Non riconoscerai la tua configurazione con SSD dedicati, rispetto a una SAN otterrai qualcosa come il miglioramento 500x anche con i file di dati e di registro delle transazioni sulla stessa unità. Un server SQL all'avanguardia avrebbe SSD separato e veloce per i dati e il registro delle transazioni su canali di controller hardware diversi (la maggior parte della scheda madre del server ne ha diversi). Ma rispetto alla tua configurazione attuale stiamo parlando di fantascienza lì. Prova SSD.

Ok, per chiunque sia interessato,

Abbiamo risolto il problema in Question un paio di mesi fa semplicemente installando unità SSD direttamente collegate in ciascuno di 3 server e spostando i dati DB e i file di registro dalla SAN a quelle unità SSD

Ecco un riepilogo di ciò che ho fatto per fare ricerche su questo problema (usando i consigli di tutti i post in questa domanda), prima di decidere di installare unità SSD:

1) ha iniziato a raccogliere i contatori PerfMon per le seguenti unità su tutti e 3 i server:

Disk F:è un disco logico basato su SAN, contiene file di dati MDF
Disk I:è un disco logico basato su SAN, contiene file di registro LDF
Disk T:è direttamente collegato SSD, dedicato esclusivamente a tempDB

L'immagine sotto è i valori medi raccolti per un periodo di 2 settimane

Disk I: (LDF)ha un IO così piccolo e la latenza è molto bassa, quindi il disco I: può essere ignorato
Puoi vedere che Disk T: (TempDB)ha un IO maggiore rispetto a Disk F: (MDF), e ha una latenza molto migliore allo stesso tempo - 0 ms

Ovviamente qualcosa non va con il disco F: dove risiedono i file di dati, ha un'alta latenza e una coda di scrittura media del disco, nonostante un IO basso

2) Latenza controllata per singoli database tramite query da questo sito Web

https://www.brentozar.com/blitz/slow-storage-reads-writes/

Pochi database attivi sul server primario avevano una latenza di lettura di 150-250 ms e latenza di scrittura di 150-450 ms
Ciò che è interessante, i file di database master e msdb avevano una latenza di lettura fino a 90 ms, il che è sospetto data la piccola dimensione dei loro dati e un basso IO - un'altra indicazione che qualcosa non va nella SAN

3) Non c'erano tempi specifici

Durante il quale sono stati visualizzati i messaggi "SQL Server ha riscontrato occorrenze ..."
Non sono stati eseguiti ETL di manutenzione o disco pesante durante la registrazione di tali messaggi

4) Visualizzatore eventi di Windows

Non ha mostrato altre voci che suggerirebbero il problema, tranne "SQL Server ha riscontrato occorrenze ..."

5) Ho iniziato a controllare le prime 10 query

Da sp_BlitzCache (CPU, letture, ecc.) E l'ottimizzazione ove possibile
Nessuna query super IO pesante che produrrebbe tonnellate di dati e influirebbe pesantemente sull'archiviazione , sebbene l'
indicizzazione nei database sia OK, lo mantengo

6) Non abbiamo un team SAN

Abbiamo solo 1 amministratore di sistema che aiuta nel
percorso di rete di occasione verso SAN: è multipath, ciascuno dei 3 server ha 2 cavi di rete che portano agli switch e quindi a SAN, e dovrebbe essere 1 Gigabyte / sec

7) Non ci sono stati risultati CrystalDiskMark

O qualsiasi altro risultato del test di benchmark da quando i server sono stati configurati, quindi non so quali dovrebbero essere le velocità , e non è possibile fare un benchmark a questo punto per vedere quali sono le velocità attualmente, poiché avrebbe influito sulla produzione

8) Imposta la sessione Eventi estesi sull'evento checkpoint per il database in questione

La sessione XE ha aiutato a scoprire che durante i messaggi "SQL Server ha riscontrato occorrenze ...", il checkpoint si è verificato molto lentamente (fino a 90 secondi)

9) Registro errori SQL Server

Voci "Saturazione" contenute "FlushCache"
Presumibilmente visualizzate quando il tempo del checkpoint per un determinato database supera le impostazioni dell'intervallo di recupero

I dettagli hanno mostrato che la quantità di dati che il checkpoint sta tentando di svuotare è piccola e ci vuole molto tempo per completarla, e la velocità complessiva è di circa 0,25 MB / sec ... strano

10) Infine, questa immagine mostra il grafico per la risoluzione dei problemi di archiviazione:

Sembra che abbiamo semplicemente un "Problema hardware: - Collaborare con l'amministratore di sistema / il fornitore dell'hardware per correggere qualsiasi configurazione errata di SAN, driver vecchi / difettosi, controller, firmware, ecc."

In un'altra domanda "Checkpoint lento ..." Checkpoint lento e avvisi I / O di 15 secondi su memoria flash Sean aveva un elenco molto bello di quali elementi devono essere controllati a livello hardware e software per la risoluzione dei problemi

Il nostro amministratore di sistema non ha potuto controllare tutte le cose dall'elenco, quindi abbiamo semplicemente scelto di gettare un po 'di hardware a questo problema - non era affatto costoso

Risoluzione:

Abbiamo ordinato unità SSD da 1 TB e installate direttamente nei server

Poiché disponiamo di gruppi di disponibilità, file di dati DB migrati da SAN a SSD su repliche secondarie, quindi failover e file migrati su precedente primario Ciò ha consentito un tempo di fermo totale minimo - meno di 1 minuto

Ora ogni server ha una copia locale dei dati DB e i backup completi / diff / log vengono eseguiti nella SAN menzionata.
Non più messaggi "SQL Server ha riscontrato occorrenze ..." nei registri di Visualizzatore eventi di Windows e prestazioni di backup, controlli di integrità, ricostruzioni di indici, query ecc. sono aumentate in modo significativo

Quante prestazioni in termini di latenza IO sono migliorate da quando abbiamo migrato i file DB su SSD?

Per valutare l'impatto, sono state utilizzate le registrazioni di Performance Monitor di Windows 2 settimane prima della migrazione e 4 settimane dopo la migrazione:

Di seguito è riportato anche il confronto delle statistiche di latenza a livello di DB (utilizzate le statistiche dei file virtuali acquisite di SQL Server prima e dopo la migrazione)

Sommario

Ne è valsa la pena la migrazione da SAN a SSD locali direttamente collegati. Ha avuto un grande impatto sulla latenza dello storage e è migliorato in media di oltre il 90% (in particolare le operazioni WRITE) e non abbiamo più picchi di 20-50 secondi in IO

Il passaggio all'SSD locale ha risolto non solo i problemi di prestazioni di archiviazione ma anche la sicurezza dei dati di cui ero preoccupato (se la SAN non riesce, tutti e 3 i server perdono i loro dati contemporaneamente)