I denne fortsættelse af min 'knee-jerk performance tuning'-serie vil jeg gerne diskutere Solid State Disks (SSD'er) og nogle af de problemer, jeg ser med deres brug i et SQL Server-miljø. For en dybdegående beskrivelse af SSD'er, tjek denne Wikipedia-artikel.
Hvad gør SSD'er for SQL Server-ydeevne?
SSD'er har ingen bevægelige dele, så når der sker en læsning eller skrivning, er der næsten ingen I/O-latens. Latensen i et roterende drev kommer fra to ting:
- Flytning af diskhovedet til det rigtige spor på diskoverfladen (kendt som søgetiden)
- Venter på, at disken drejer til det rigtige punkt på sporet (kendt som rotationsforsinkelsen)
Det betyder, at SSD'er giver et stort ydelsesboost, når der er en I/O-flaskehals.
Så enkelt er det.
Der er en smule komplikation, der er værd at nævne, men uden for rammerne af denne artikel for at gå i dybden:SSD-ydeevne kan begynde at blive forringet, efterhånden som drevet bliver virkelig fuldt (undersøgt og forklaret i detaljer i denne artikel fra AnandTech). Der kan også kræves noget systemhukommelse til SSD-driveren for at hjælpe med slidudjævning (forlænger levetiden af NAND-cellerne i SSD'en), og det vil variere fra leverandør til leverandør. Nok om det – tilbage til SQL Server-tingene.
Undgå dårlige internetråd
Der er to bidder af meget dårlige råd, jeg ser på internettet omkring SQL Server og SSD'er.
Den første er omkring, hvad du skal sætte på SSD'en, hvor rådet er altid at lægge tempdb og dine transaktionslogfiler på SSD'er. Ved første øjekast lyder det som et godt råd, da transaktionslogfiler og tempdb ofte er flaskehalse i systemet.
Men hvad hvis de ikke er det?
Din arbejdsbyrde kan for det meste være læst, i hvilket tilfælde transaktionsloggen sandsynligvis ikke vil være en flaskehals for arbejdsbelastningen, og det kan derfor være spild af en dyr SSD at sætte den på en SSD.
Din tempdb bliver muligvis ikke brugt særlig meget af din arbejdsbyrde, så at sætte den på en SSD kan være spild af en dyr SSD.
Når du overvejer, hvilken del af SQL Server-miljøet du skal flytte til SSD'en, vil du undersøge, hvor I/O-flaskehalsene er. Dette kan gøres meget nemt ved at bruge den kode, jeg postede i sidste uge, der bruger sys.dm_io_virtual_file_stats DMV til at give et øjebliksbillede af I/O-latenserne for alle filer i alle databaser på instansen. For at give mening med dine latency-tal og sammenligne dem med gode/dårlige værdier, læs dette lange indlæg, jeg lavede specifikt omkring tempdb og transaktionslog I/O-forsinkelser.
Og selvom du har høje latenstider, så lad være med at gå i knæ og tro, at den eneste løsning er at flytte den eller de dårligt ydende filer til en SSD:
- For datafillæsningsforsinkelser skal du undersøge, hvorfor der sker så mange læsninger. Det dækker jeg her.
- For logfilskriveforsinkelser skal du overveje alle måder at justere loggens ydeevne og hvad der bliver logget på. Jeg dækker det her, her og her.
Det værst tænkelige tilfælde er, hvor du får en masse SSD'er, følg internetrådene for at flytte tempdb og dine logfiler til dem, og så er der ingen gevinst i arbejdsbelastningen. Det vil ikke tilskynde din ledelse til at give dig dyrere SSD'er.
Det andet dårlige råd er omkring indeksfragmentering, hvor rådet er, at fordi SSD'er er så hurtige, behøver du ikke bekymre dig om indeksfragmentering, når du bruger SSD'er.
Hvilket sludder!
Der er tre måder, jeg afviser det dårlige råd på:
- SSD'er stopper på ingen måde årsagen til indeksfragmentering:sideopdelinger fra sider, der har brug for ledig plads til en tilfældig indsættelse eller udvidelse af rækkestørrelsen. En sideopdeling genererer den samme mængde transaktionslog, ressourceforbrug og potentielle tråde, uanset hvor data/logfilerne er gemt.
- Indeksfragmentering omfatter at have mange data/indekssider med lav sidetæthed (dvs. masser af tom, ledig plads). Vil du virkelig have dine dyre SSD'er til at gemme masser af tom plads? SSD'er hjælper overhovedet ikke her.
- Min kollega Jonathan Kehayias foretog en dybdegående undersøgelse ved hjælp af udvidede hændelser af I/O-mønstre omkring indeksfragmentering specifikt for at imødegå dette dårlige råd og fandt ud af, at der stadig er et præstationshit ved at have indeksfragmentering, når man bruger SSD'er. Du kan læse hans lange indlæg her.
Det eneste, SSD'er gør omkring indeksfragmentering, er at få aflæsningerne til at gå hurtigere, så der er mindre ydeevnesstraf for indeksområdescanninger, når der findes indeksfragmentering, men punkt 3 ovenfor viser, at der stadig er en straf.
SSD'er ændrer ikke, hvordan du håndterer og/eller forhindrer indeksfragmentering i dit SQL Server-miljø.
Sørg for at beskytte dine data
En af de kardinalsynder, jeg ser folk begå ved at bruge SSD'er, er kun at bruge en af dem. Med kun ét drev, hvilket RAID-niveau bruger du? Nul. RAID-0 giver ingen redundans overhovedet.
Hvis du skal bruge en SSD, skal du bruge mindst to i en RAID-1 (spejling) konfiguration. Det nytter ikke at have et ydelsesboost, hvis du ofrer tilgængeligheden af systemet som en afvejning.
Et tilbageskud, jeg nogle gange får til at bruge mindst to SSD'er, er, at SSD-kortet leverer to drev til Windows, og så er det helt sikkert det samme som RAID-1 på tværs af to fysisk adskilte SSD'er at oprette en Windows-spejlet volumen over de to drev?
Nej det er ikke. Det er stadig en fysisk SSD uden redundans. Har du nogensinde set halvdelen af et SSD-kort fejle? Nej, det har jeg heller ikke. Gør det rigtigt og brug to af dem og få reel redundans for dine data.
Det andet tilbageslag, jeg får, er, at de er SSD'er, ikke roterende drev, så de kommer ikke til at fejle. Det er forkert. SSD'er kan og fejler ligesom roterende drev. Jeg har personligt set to SSD'er i virksomhedskvalitet fejle under test i vores laboratoriemiljø. Ifølge denne artikel på StorageReview.com har SSD'er i forbrugerkvalitet en MTBF på 2 millioner timer mod 1,5 millioner timer for spinningdrev i forbrugerkvalitet, og jeg ville forvente lignende resultater for drev i virksomhedskvalitet, men SSD'er fejler.
Oversigt
Gå ikke i fælden med at tro, at uanset hvad du sætter på SSD'en betyder, at du får et boost i ydeevnen - du skal vælge og vrage med omhu. Og tro heller ikke på det nonsens derude om at ignorere indeksfragmentering, når du bruger SSD'er.
SSD'er er en meget nyttig måde at øge ydeevnen på, men for deres omkostninger vil du sikre dig, at du maksimerer afkastet af din virksomheds investering ved at bruge dem korrekt og kun hvor det er relevant.
I den næste artikel i serien vil jeg diskutere en anden almindelig årsag til knæstød præstationsjustering. Indtil da, god fejlfinding!