In dit vervolg op mijn serie 'knee-jerk performance tuning' wil ik het hebben over Solid State Disks (SSD's) en enkele van de problemen die ik zie bij het gebruik ervan in een SQL Server-omgeving. Bekijk dit Wikipedia-artikel voor een uitgebreide beschrijving van SSD's.
Wat doen SSD's voor de prestaties van SQL Server?
SSD's hebben geen bewegende delen, dus als er wordt gelezen of geschreven, is er bijna geen I/O-latentie. De latentie in een draaiende schijf komt van twee dingen:
- De schijfkop naar het juiste spoor op het schijfoppervlak verplaatsen (bekend als de zoektijd)
- Wachten tot de schijf naar het juiste punt op de track draait (bekend als de rotatielatentie)
Dit betekent dat SSD's een grote prestatieverbetering bieden wanneer er een I/O-knelpunt is.
Zo simpel is het.
Er is een beetje complicatie die het vermelden waard is, maar buiten het bestek van dit artikel om dieper op in te gaan:SSD-prestaties kunnen beginnen te verslechteren als de schijf echt vol raakt (onderzocht en in detail uitgelegd in dit artikel van AnandTech). Er kan ook wat systeemgeheugen nodig zijn voor het SSD-stuurprogramma om te helpen bij slijtage-nivellering (het verlengen van de levensduur van de NAND-cellen in de SSD), en dat zal per leverancier verschillen. Genoeg daarover - terug naar de SQL Server-dingen.
Vermijd slecht internetadvies
Er zijn twee zeer slechte adviezen die ik op internet zie rond SQL Server en SSD's.
De eerste gaat over wat je op de SSD moet zetten, waarbij het advies is om altijd tempdb en je transactielogboeken op SSD's te zetten. Op het eerste gezicht klinkt dat als een goed advies, aangezien transactielogboeken en tempdb vaak knelpunten in het systeem zijn.
Maar wat als ze dat niet zijn?
Uw werkbelasting kan voornamelijk worden gelezen, in welk geval het transactielogboek waarschijnlijk geen bottleneck voor de werkbelasting zal zijn en dus kan het een verspilling van een dure SSD zijn om het op een SSD te plaatsen.
Uw tempdb wordt mogelijk niet veel gebruikt door uw werklast, dus het op een SSD plaatsen kan een verspilling van een dure SSD zijn.
Wanneer je overweegt welk deel van de SQL Server-omgeving je naar de SSD wilt verplaatsen, wil je onderzoeken waar de I/O-knelpunten zitten. Dit kan heel eenvoudig worden gedaan met behulp van de code die ik vorige week heb gepost en die de DMV sys.dm_io_virtual_file_stats gebruikt om een momentopname te maken van de I/O-latenties voor alle bestanden in alle databases op de instantie. Om je latentiecijfers te begrijpen en ze te vergelijken met goede/slechte waarden, lees je dit lange bericht dat ik specifiek heb gedaan rond tempdb en transactielogboek I/O-latenties.
En zelfs als je hoge latenties hebt, moet je niet kniezen en denken dat de enige oplossing is om het (de) slecht presterende bestand(en) naar een SSD te verplaatsen:
- Onderzoek voor leesvertragingen van gegevensbestanden waarom er zoveel leesbewerkingen plaatsvinden. Ik behandel dat hier.
- Overweeg voor vertragingen bij het schrijven van logbestanden alle manieren om de prestaties van het logboek af te stemmen en wat er wordt vastgelegd. Ik behandel dat hier, hier en hier.
In het slechtst mogelijke geval krijgt u een heleboel SSD's, volgt u het internetadvies om tempdb en uw logbestanden naar hen te verplaatsen, en dan is er geen prestatiewinst op de werkbelasting. Dat zal uw management niet aanmoedigen om u duurdere SSD's aan te bieden.
Het tweede slechte advies gaat over indexfragmentatie, waarbij het advies luidt dat omdat SSD's zo snel zijn, u zich geen zorgen hoeft te maken over indexfragmentatie bij het gebruik van SSD's.
Wat een onzin!
Er zijn drie manieren waarop ik dat slechte advies kan weerleggen:
- SSD's stoppen op geen enkele manier de oorzaak van indexfragmentatie:pagina's worden gesplitst van pagina's die vrije ruimte nodig hebben voor een willekeurige invoeging of toename van de rijgrootte. Een paginasplitsing genereert dezelfde hoeveelheid transactielogboek, resourcegebruik en potentiële threadwachten, ongeacht waar de gegevens/logbestanden zijn opgeslagen.
- Indexfragmentatie omvat het hebben van veel gegevens-/indexpagina's met een lage paginadichtheid (d.w.z. veel lege, vrije ruimte). Wilt u echt dat uw dure SSD's veel lege ruimte opslaan? SSD's helpen hier helemaal niet.
- Mijn collega Jonathan Kehayias deed diepgaand onderzoek, met behulp van Extended Events, naar I/O-patronen rond indexfragmentatie, specifiek om dit slechte advies aan te pakken en ontdekte dat er nog steeds een prestatieverlies is door indexfragmentatie bij het gebruik van SSD's. Je kunt zijn lange post hier lezen.
Het enige dat SSD's doen rond indexfragmentatie, is dat het lezen sneller gaat, dus er is minder prestatieverlies voor indexbereikscans wanneer indexfragmentatie bestaat, maar punt 3 hierboven laat zien dat er nog steeds een boete is.
SSD's veranderen niets aan de manier waarop u omgaat met en/of het voorkomen van indexfragmentatie in uw SQL Server-omgeving.
Zorg ervoor dat u uw gegevens beschermt
Een van de hoofdzonden die ik mensen zie begaan rond het gebruik van SSD's, is dat ze er maar één gebruiken. Welk RAID-niveau gebruikt u met slechts één schijf? Nul. RAID-0 biedt helemaal geen redundantie.
Als je een SSD gaat gebruiken, dan moet je er minimaal twee gebruiken, in een RAID-1 (mirroring) configuratie. Het heeft geen zin om een prestatieverbetering te hebben als je de beschikbaarheid van het systeem opoffert als compromis.
Een nadeel dat ik soms krijg bij het gebruik van ten minste twee SSD's, is dat de SSD-kaart twee schijven aan Windows levert, en het creëren van een Windows-gespiegeld volume over de twee schijven is dus zeker hetzelfde als RAID-1 over twee fysiek gescheiden SSD's?
Nee dat is het niet. Het is nog steeds één fysieke SSD, zonder redundantie. Heb je ooit de helft van een SSD-kaart zien falen? Nee, ik ook niet. Doe het goed en gebruik er twee en zorg voor echte redundantie voor uw gegevens.
De andere push-back die ik krijg, is dat het SSD's zijn, geen draaiende schijven, dus niet zullen falen. Dat is verkeerd. SSD's kunnen en zullen falen, net als draaiende schijven. Ik heb persoonlijk twee SSD's van bedrijfskwaliteit zien falen tijdens het testen in onze laboratoriumomgeving. Volgens dit artikel op StorageReview.com hebben SSD's van consumentenkwaliteit een MTBF van 2 miljoen uur versus 1,5 miljoen uur voor draaiende schijven van consumentenkwaliteit, en ik zou vergelijkbare resultaten verwachten voor schijven van bedrijfskwaliteit, maar SSD's falen.
Samenvatting
Trap niet in de val door te denken dat wat je ook op de SSD zet, je een prestatieverbetering zal opleveren - je moet zorgvuldig kiezen en kiezen. En geloof de onzin die er is over het negeren van indexfragmentatie bij het gebruik van SSD's ook niet.
SSD's zijn een zeer nuttige manier om de prestaties te verbeteren, maar voor hun kosten wilt u er zeker van zijn dat u het rendement op de investering van uw bedrijf maximaliseert door ze correct en alleen waar nodig te gebruiken.
In het volgende artikel in de serie bespreek ik een andere veelvoorkomende oorzaak van het afstemmen van de prestaties. Tot dan, veel plezier met het oplossen van problemen!