In questa continuazione della mia serie di "ottimizzazione delle prestazioni istintive", vorrei discutere dei dischi a stato solido (SSD) e di alcuni dei problemi che vedo con il loro utilizzo in un ambiente SQL Server. Per una descrizione approfondita degli SSD, dai un'occhiata a questo articolo di Wikipedia.
Cosa fanno gli SSD per le prestazioni di SQL Server?
Gli SSD non hanno parti mobili, quindi quando si verifica una lettura o una scrittura, non c'è quasi nessuna latenza di I/O. La latenza in un'unità rotante deriva da due cose:
- Spostamento della testina del disco sulla traccia giusta sulla superficie del disco (noto come tempo di ricerca)
- Aspettando che il disco ruoti fino al punto giusto della traccia (noto come latenza rotazionale)
Ciò significa che gli SSD offrono un notevole incremento delle prestazioni in caso di collo di bottiglia di I/O.
È così semplice.
C'è un po' di complicazione che vale la pena menzionare, ma va oltre lo scopo di questo articolo per approfondire:le prestazioni dell'SSD possono iniziare a peggiorare quando l'unità si riempie davvero (esaminata e spiegata in dettaglio in questo articolo di AnandTech). Potrebbe anche essere necessaria della memoria di sistema per il driver SSD per aiutare con il livellamento dell'usura (prolungando la vita delle celle NAND nell'SSD) e questo varierà in base al fornitore. Basta con questo:torniamo alle cose di SQL Server.
Evita cattivi consigli su Internet
Ci sono due consigli molto scarsi che vedo su Internet su SQL Server e SSD.
Il primo riguarda cosa mettere sull'SSD, dove il consiglio è di mettere sempre tempdb e i registri delle transazioni su SSD. A prima vista sembra un buon consiglio, poiché i log delle transazioni e il tempdb sono comunemente colli di bottiglia nel sistema.
E se non lo fossero?
Il tuo carico di lavoro potrebbe essere principalmente di lettura, nel qual caso il registro delle transazioni probabilmente non sarà un collo di bottiglia del carico di lavoro e quindi inserirlo su un SSD potrebbe essere uno spreco di un costoso SSD.
Il tuo tempdb potrebbe non essere utilizzato molto dal tuo carico di lavoro, quindi metterlo su un SSD potrebbe essere uno spreco di un costoso SSD.
Quando si considera quale parte dell'ambiente SQL Server spostare sull'SSD, si desidera esaminare dove si trovano i colli di bottiglia di I/O. Questo può essere fatto molto facilmente utilizzando il codice che ho pubblicato la scorsa settimana che utilizza il DMV sys.dm_io_virtual_file_stats per fornire un'istantanea delle latenze di I/O per tutti i file in tutti i database nell'istanza. Per dare un senso ai tuoi numeri di latenza e confrontarli con valori buoni/cattivi, leggi questo lungo post che ho scritto specificamente sulle latenze di I/O di tempdb e log delle transazioni.
E poi, anche se hai latenze elevate, non pensare che l'unica soluzione sia spostare i file con prestazioni scadenti su un SSD:
- Per le latenze di lettura dei file di dati, indagare sul motivo per cui si verificano così tante letture. Ne parlo qui.
- Per le latenze di scrittura dei file di registro, considera tutti i modi per ottimizzare le prestazioni del registro e ciò che viene registrato. Ne parlo qui, qui e qui.
Il peggior caso possibile è quando ti vengono forniti un sacco di SSD, segui i consigli di Internet per spostare tempdb e i tuoi file di registro su di essi e quindi non c'è alcun aumento delle prestazioni del carico di lavoro. Ciò non incoraggerà il tuo management a fornirti SSD più costosi.
Il secondo consiglio scadente riguarda la frammentazione dell'indice, dove il consiglio è che, poiché gli SSD sono così veloci, non devi preoccuparti della frammentazione dell'indice quando usi gli SSD.
Che sciocchezza!
Ci sono tre modi in cui confuto quel cattivo consiglio:
L'unica cosa che fanno gli SSD in merito alla frammentazione dell'indice è rendere le letture più veloci, quindi c'è una riduzione delle prestazioni per le scansioni dell'intervallo di indici quando esiste la frammentazione dell'indice, ma il punto 3 sopra mostra che c'è ancora una penalità.
Gli SSD non cambiano il modo in cui gestisci e/o previene la frammentazione dell'indice nel tuo ambiente SQL Server.
Assicurati di proteggere i tuoi dati
Uno dei peccati capitali che vedo che le persone si commettono usando gli SSD è usarne solo uno. Con una sola unità, quale livello RAID stai utilizzando? Zero. RAID-0 non fornisce alcuna ridondanza.
Se hai intenzione di utilizzare un SSD, devi usarne almeno due, in una configurazione RAID-1 (mirroring). Non ha senso aumentare le prestazioni se stai sacrificando la disponibilità del sistema come compromesso.
Un ostacolo che a volte riesco a utilizzare almeno due SSD è che la scheda SSD fornisce due unità a Windows, quindi sicuramente la creazione di un volume con mirroring di Windows sulle due unità è la stessa di RAID-1 su due SSD fisicamente separati?
No non lo è. È ancora un SSD fisico, senza ridondanza. Hai mai visto la metà di una scheda SSD fallire? No, nemmeno io. Fallo bene e usane due e ottieni una vera ridondanza per i tuoi dati.
L'altro ostacolo che ottengo è che sono SSD, non unità rotanti, quindi non falliranno. È sbagliato. Gli SSD possono e falliscono proprio come le unità rotanti. Ho visto personalmente due SSD di livello aziendale fallire durante i test nel nostro ambiente di laboratorio. Secondo questo articolo su StorageReview.com, gli SSD di livello consumer hanno un MTBF di 2 milioni di ore rispetto a 1,5 milioni di ore per le unità rotanti di livello consumer e mi aspetterei risultati simili per le unità di livello enterprise, ma gli SSD falliscono.
Riepilogo
Non cadere nella trappola di pensare che qualunque cosa tu metta sull'SSD significhi che otterrai un aumento delle prestazioni:devi scegliere e scegliere con attenzione. E non credere nemmeno alle sciocchezze sull'ignorare la frammentazione dell'indice quando si utilizzano gli SSD.
Gli SSD sono un modo molto utile per aumentare le prestazioni, ma per il loro costo, vuoi assicurarti di massimizzare il ritorno sull'investimento della tua azienda utilizzandoli correttamente e solo dove appropriato.
Nel prossimo articolo della serie, discuterò un'altra causa comune dell'ottimizzazione delle prestazioni istintiva. Fino ad allora, buona risoluzione dei problemi!
