I den här fortsättningen av min "knee-jerk performance tuning"-serie, skulle jag vilja diskutera Solid State Disks (SSD) och några av de problem jag ser med deras användning i en SQL Server-miljö. För en djupgående beskrivning av SSD:er, kolla in den här Wikipedia-artikeln.
Vad gör SSD:er för SQL Server-prestanda?
SSD:er har inga rörliga delar så när en läsning eller skrivning inträffar finns det nästan ingen I/O-latens. Latensen i en snurrande enhet kommer från två saker:
- Flytta skivhuvudet till rätt spår på skivytan (känd som söktiden)
- Väntar på att skivan ska snurra till rätt punkt på spåret (känd som rotationsfördröjningen)
Det betyder att SSD ger en stor prestandaökning när det finns en I/O-flaskhals.
Så enkelt är det.
Det finns lite komplikationer som är värt att nämna men utanför ramen för denna artikel för att gå in på djupet:SSD-prestandan kan börja försämras när enheten blir riktigt full (undersöks och förklaras i detalj i den här artikeln från AnandTech). Det kan också behövas lite systemminne för SSD-drivrutinen för att hjälpa till med slitageutjämning (förlänger livslängden för NAND-cellerna i SSD), och det kommer att variera beroende på leverantör. Nog om det – tillbaka till SQL Server-grejen.
Undvik dåliga internetråd
Det finns två mycket dåliga råd jag ser på Internet kring SQL Server och SSD:er.
Den första handlar om vad man ska lägga på SSD:n, där rådet är att alltid lägga tempdb och dina transaktionsloggar på SSD:er. Vid första anblicken låter det som ett bra råd, eftersom transaktionsloggar och tempdb ofta är flaskhalsar i systemet.
Men vad händer om de inte är det?
Din arbetsbelastning kan vara läsbar, i vilket fall transaktionsloggen sannolikt inte kommer att utgöra en flaskhals för arbetsbelastningen och så att lägga den på en SSD kan vara ett slöseri med en dyr SSD.
Din tempdb kanske inte används särskilt mycket av din arbetsbelastning, så att lägga den på en SSD kan vara ett slöseri med en dyr SSD.
När du funderar på vilken del av SQL Server-miljön som ska flyttas till SSD:n, vill du undersöka var I/O-flaskhalsarna finns. Detta kan göras mycket enkelt med koden jag postade förra veckan som använder sys.dm_io_virtual_file_stats DMV för att ge en ögonblicksbild av I/O-latenserna för alla filer i alla databaser på instansen. För att förstå dina latenssiffror och jämföra dem med bra/dåliga värden, läs igenom det här långa inlägget jag gjorde specifikt kring tempdb och transaktionslogg I/O-latenser.
Och även om du har höga latenser, tänk inte på att den enda lösningen är att flytta den/de dåligt presterande filen/filerna till en SSD:
- För datafilens läsfördröjningar, undersök varför det finns så många läsningar. Jag täcker det här.
- För skrivfördröjningar för loggfiler bör du överväga alla sätt att justera loggens prestanda och vad som loggas. Jag täcker det här, här och här.
Det värsta tänkbara fallet är när du får ett gäng SSD:er, följ internetråden för att flytta tempdb och dina loggfiler till dem, och då finns det ingen prestandavinst i arbetsbelastningen. Det kommer inte att uppmuntra din ledning att förse dig med dyrare SSD-enheter.
Det andra dåliga rådet handlar om indexfragmentering, där rådet är att eftersom SSD:er är så snabba behöver du inte oroa dig för indexfragmentering när du använder SSD:er.
Vilket nonsens!
Det finns tre sätt jag motbevisar det dåliga rådet:
- SSD:er stoppar inte på något sätt orsaken till indexfragmentering:siddelningar från sidor som behöver ledigt utrymme för en slumpmässig infogning eller ökning av radstorleken. En siddelning genererar samma mängd transaktionslogg, resursanvändning och potentiella trådväntningar oavsett var data/loggfiler lagras.
- Indexfragmentering inkluderar att ha många data-/indexsidor med låg siddensitet (dvs. massor av tomt, ledigt utrymme). Vill du verkligen att dina dyra SSD-enheter ska lagra massor av tomt utrymme? SSD-enheter hjälper inte alls här.
- Min kollega Jonathan Kehayias gjorde en djupgående undersökning, med hjälp av Extended Events, av I/O-mönster kring indexfragmentering specifikt för att ta itu med detta dåliga råd och fann att det fortfarande finns en prestandaträff från att ha indexfragmentering när man använder SSD. Du kan läsa hans långa inlägg här.
Det enda SSD-enheter gör kring indexfragmentering är att få avläsningarna att gå snabbare, så det är mindre prestandastraff för indexintervallsskanningar när indexfragmentering finns, men punkt 3 ovan visar att det fortfarande finns ett straff.
SSD:er ändrar inte hur du hanterar och/eller förhindrar indexfragmentering i din SQL Server-miljö.
Se till att skydda dina data
En av de kardinalsynder som jag ser människor begå när de använder SSD är att bara använda en av dem. Med bara en enhet, vilken RAID-nivå använder du? Noll. RAID-0 ger ingen redundans alls.
Om du ska använda en SSD måste du använda minst två, i en RAID-1 (spegling) konfiguration. Det är ingen idé att ha en prestandahöjning om du offrar systemets tillgänglighet som en kompromiss.
Ett tillbakadrag jag ibland får till att använda minst två SSD-enheter är att SSD-kortet tillhandahåller två enheter till Windows, så att skapa en Windows-spegelvolym över de två enheterna är väl detsamma som RAID-1 över två fysiskt separata SSD-enheter?
Nej det är det inte. Det är fortfarande en fysisk SSD, utan redundans. Har du någonsin sett hälften av ett SSD-kort misslyckas? Nej, inte jag heller. Gör det rätt och använd två av dem och få verklig redundans för din data.
Den andra stöten jag får är att de är SSD:er, inte snurrande enheter, så de kommer inte att misslyckas. Det är fel. SSD-enheter kan och misslyckas precis som snurrande enheter. Jag har personligen sett två SSD:er av företagsklass misslyckas under testning i vår labbmiljö. Enligt den här artikeln på StorageReview.com har SSD-enheter för konsumentklass en MTBF på 2 miljoner timmar mot 1,5 miljoner timmar för snurrande enheter för konsumentklass, och jag förväntar mig liknande resultat för enheter av företagsklass, men SSD-enheter misslyckas.
Sammanfattning
Gå inte i fällan att tro att vad du än lägger på SSD:n betyder att du kommer att få en boost i prestanda – du måste välja och vraka noggrant. Och tro inte på nonsensen där ute om att ignorera indexfragmentering när du använder SSD:er heller.
SSD:er är ett mycket användbart sätt att öka prestandan, men för deras kostnad vill du vara säker på att du maximerar avkastningen på ditt företags investering genom att använda dem korrekt och endast där det är lämpligt.
I nästa artikel i serien kommer jag att diskutera en annan vanlig orsak till knee-jerk prestandajustering. Tills dess, glad felsökning!