De primaire focus van deze blogsite is prestaties in een SQL Server-omgeving. Je zou kunnen stellen dat performance begint bij het ontwerpen van databases en applicaties. Maar je kunt ook stellen dat het hebben van de juiste middelen essentieel is voor goede prestaties. Voor alle discussies over de juiste bronnen (welk CPU-model, hoeveel geheugen, wat voor soort opslag), verwaarlozen we soms de handeling van capaciteitsplanning:met behulp van de gegevens die we hebben om weloverwogen beslissingen te nemen over wat we nodig hebben . Capaciteitsplanning is niet alleen uitzoeken hoeveel schijfruimte we nodig hebben, het omvat ook de bronnen die een SQL Server-instantie beschikbaar moet hebben om de werklast aan te kunnen.
Nieuw of bestaand?
Capaciteitsplanning voor een nieuwe oplossing is echt lastig. U moet schattingen maken over de werklast op basis van informatie die u van het bedrijf verzamelt. Dit betekent dat je moeilijke vragen moet stellen over hoeveel gegevens ze in de eerste maand, de eerste zes maanden en het eerste jaar zullen verwachten. Wanneer er een nieuwe oplossing binnenkomt, is dit vaak het LAATSTE waar het bedrijf aan denkt, dus heel vaak krijg je vage antwoorden. In het geval van een nieuwe oplossing moet u echt een beste gok doen. Trek je haar niet uit om exacte cijfers te krijgen.
Als de oplossing van een leverancier is, moet u de leverancier om planningsaanbevelingen vragen over zowel de benodigde ruimte als de benodigde middelen. Ik geef toe dat ze die gegevens misschien niet hebben, maar je krijgt niet waar je niet om vraagt. Het kan nooit kwaad om het te proberen.
[Bonus:als de leverancier geen informatie heeft om te verstrekken, zou het dan niet handig zijn als u, nadat het systeem een paar maanden actief is geweest, uw gegevens stuurt... zoals welke hardware u heeft , en hoe ziet de werkdruk eruit? Het hoeft geen 20-pagina's tellend artikel te zijn, maar de feedback zou hen in de richting kunnen duwen om in de toekomst proactiever te zijn.]
In termen van een bestaande oplossing, als je een prestatieprobleem hebt of als je hardware wilt upgraden, wil je informatie over de huidige omgeving vastleggen om een nieuwe te plannen.
Opslag
Plannen voor het bedrag van de benodigde opslagruimte is vrij eenvoudig, het vereist alleen wat planning vooraf. In mijn proactieve artikelen over de statuscontrole van SQL Server bespreek ik het bewaken van schijfruimte en voeg ik een query toe om bestandsinformatie vast te leggen. Deze query legt de grootte van de databasebestanden voor het exemplaar vast, evenals de gebruikte ruimte. Het is absoluut noodzakelijk om deze gegevens in de loop van de tijd te trenden, en dat betekent niet een paar weken. U wilt zien hoe de bestanden in de loop van maanden veranderen, mogelijk wel een tot twee jaar, omdat gebruikspatronen voor een toepassing kunnen veranderen. Deze informatie is gemakkelijk vast te leggen, vereist weinig ruimte om op te slaan en is van onschatbare waarde als referentie wanneer u opslagruimte aanschaft. Als u kwantitatieve gegevens over de groei van het systeem kunt verstrekken, heeft u een veel grotere kans om vooraf de benodigde ruimte te krijgen in plaats van er later om te moeten vragen. En als je om ruimte vraagt, zorg er dan voor dat je tempdb in je berekeningen opneemt.
Hardwarebronnen
CPU
Het optimaliseren van uw CPU-prestaties gaat niet alleen over het aantal CPU's dat u heeft, u moet ook rekening houden met het model en de werklast (bijv. datawarehouse met grote parallelle query's versus OLTP met seriële query's). Met deze informatie, en een beetje hulp van Glenn, kunt u de beste processor voor uw server bepalen. Vergeet niet rekening te houden met licentiekosten en beperkingen op basis van uw editie van SQL Server!
Geheugen
Geheugen is relatief goedkoop en het is onze aanbeveling om altijd de maximale hoeveelheid geheugen aan te schaffen die een server kan bevatten. Het lezen van gegevens uit het geheugen gaat aanzienlijk sneller dan het lezen van schijf, dus hoe meer gegevens er in het geheugen passen, hoe beter. Merk op dat de hele database niet heeft in het geheugen passen. U hebt alleen de werkset met gegevens nodig om in het geheugen te passen. Overweeg een database van 2TB. Het is onwaarschijnlijk dat in een OLTP-scenario alle 2TB elke dag wordt gebruikt. Meestal worden alleen recente gegevens geopend, misschien alleen de laatste 30 of 60 dagen. Dat zijn de gegevens die in het geheugen moeten passen. Maar natuurlijk zien we zelden een pure OLTP-omgeving, vaak is het een gemengde omgeving omdat gebruikers graag rapporten over grote datasets draaien, en er is geen datawarehouse of rapportagekopie van de database, zodat ze hebben om de rapporten te vergelijken met de productie. Dit bemoeilijkt de geheugenbehoefte. Nu heb je soms die oudere gegevens in het geheugen nodig, maar soms ook niet. Het is belangrijk om de werkdruk te begrijpen; welke soorten zoekopdrachten worden uitgevoerd op de database?
Als u Standard Edition gebruikt, controleer dan of u meer geheugen op de server heeft dan het maximaal ondersteunde geheugen. Met SQL Server 2014 en hoger is in Standard Edition bijvoorbeeld de maximale hoeveelheid geheugen die u aan de bufferpool kunt toewijzen (via de instelling voor maximaal servergeheugen) 128 GB. Daarom wilt u meer geheugen op de server hebben (bijvoorbeeld 160 GB), zodat u het maximale servergeheugen kunt instellen op de hoogst mogelijke waarde van 128 GB, en toch geheugen beschikbaar hebt voor het besturingssysteem en andere SQL Server-processen. Verder kunt u met SQL Server 2016 SP1 Standard Edition In-Memory OLTP gebruiken, met een limiet van 32 GB per database. Dit is hoger dan de maximale waarde van het servergeheugen, dus als u van plan bent deze functie te gebruiken, moet u dienovereenkomstig geheugen aanschaffen.
Opslag
Als we het hebben over prestatievereisten voor opslag, hoor je mensen vaak praten over IOPS (invoer/uitvoerbewerkingen per seconde). Dit artikel is zelfs geïnspireerd op een vraag van een kijker die mijn Pluralsight-cursus over benchmarking en baseline heeft bekeken. De vraag was:"Hoe correleert u de Performance Monitor-tellers voor lees- en schrijfbewerkingen per seconde aan gebruikersverbindingen om het aantal IO's per gebruiker te schatten?" Lees- en schrijfbewerkingen per seconde zijn de invoer-/uitvoerbewerkingen, dus we hebben deze gegevens beschikbaar via PerfMon op instantieniveau, en dit is wat u gebruikt om de IOPS-vereisten voor een instantie te definiëren.
Als u echter weet dat leest en schrijft en gebruikersverbindingen, dan kunt u wat wiskunde doen en IOPS per gebruiker berekenen. Dit is handig als u van plan bent de oplossing te laten groeien en meer gebruikers toe te voegen. U wilt er zeker van zijn dat de oplossing schaalt, en een van de opties die u heeft, is om uw berekende IOPS per gebruiker te nemen op basis van het X-aantal gebruikers, en vervolgens de instantie-IOPS te schatten voor het Y-aantal gebruikers. Nu maken we veel aannames met deze berekening. We gaan ervan uit dat de manier waarop nieuwe verbindingen het systeem gebruiken hetzelfde is als vandaag - dat kan uiteindelijk wel of niet het geval zijn, je weet het pas als het systeem is geïnstalleerd. Wanneer u deze waarde begrijpt (lezen + schrijven / gebruikersverbindingen =gemiddelde IOPS per gebruiker), dan weet u hoe u IOPS kunt inschatten voor een oplossing op basis van verwachte gebruikersverbindingen.
U neemt deze informatie vervolgens mee naar uw opslagpersoon om de mogelijke beschikbare configuraties te bespreken. U kunt de maximale IOPS voor een schijfconfiguratie berekenen, mits u informatie heeft over de schijven (bijvoorbeeld het aantal schijven, de snelheid, de grootte en de RAID-configuratie). U kunt de IO-doorvoer voor een schijf testen met CrystalDiskMark, hoewel dit misschien niet mogelijk is als de opslag niet is bepaald. Als het eenmaal op zijn plaats is, moet u deze tests uitvoeren om er zeker van te zijn dat de IOPS voor een bepaalde schijf aan de verwachte werkbelasting kan voldoen.
IOPS is slechts één manier om naar opslagprestaties te kijken. Begrijp dat deze gegevens u vertellen hoeveel IO er plaatsvindt, en idealiter, als u IOPS kent en u de opslag heeft om aan de vereisten te voldoen, zou de latentie minimaal moeten zijn. Maar latentie is wat de prestaties beïnvloedt. Om te bepalen welke latentie bestaat, moet u een tool zoals DiskSpd gebruiken om de opslag te benchmarken. Glenn heeft een geweldig artikel waarin wordt uitgelegd hoe IO-prestaties kunnen worden geanalyseerd, en dan nog een artikel over hoe u DiskSpd kunt gebruiken om het te testen om de latentie te begrijpen. Ik raad je ten zeerste aan om beide artikelen te lezen als je nog niet eerder naar opslag en prestaties hebt gekeken.
Conclusie
Capaciteitsplanning gaat over meer dan alleen weten hoeveel ruimte u nodig heeft voor databasebestanden. U moet de werkbelasting begrijpen en begrijpen wat deze vereist in termen van CPU, geheugen en schijfbronnen. Om dit te doen, hebt u gegevens nodig ... wat betekent dat u basislijnen voor het vastleggen nodig hebt. Mijn allereerste sessie in de SQL Server-gemeenschap was in december 2010 en het ging over baselines. Zes jaar later heb ik het nog steeds over hun belang, en ik hoor nog steeds van mensen dat ze deze cijfers niet hebben. Als u intelligente, gerichte capaciteitsplanning wilt doen, moet u de juiste gegevens verzamelen... anders blijft u gissen.