Det primære fokus på denne blogside er ydeevne i et SQL Server-miljø. Man kan argumentere for, at ydeevne starter med database- og applikationsdesign. Men du kan også argumentere for, at det er essentielt at have de rigtige ressourcer til rådighed for en god præstation. På grund af al diskussionen om de rigtige ressourcer (hvilken CPU-model, hvor meget hukommelse, hvilken slags lagerplads), forsømmer vi nogle gange handlingen med kapacitetsplanlægning:ved at bruge de data, vi har at træffe informerede beslutninger om, hvad vi har brug for . Kapacitetsplanlægning er ikke kun at finde ud af, hvor meget diskplads vi har brug for, det involverer også de ressourcer, som en SQL Server-instans skal have til rådighed for at håndtere arbejdsbyrden.
Ny eller eksisterende?
Kapacitetsplanlægning for en ny løsning er virkelig vanskelig. Du skal komme med estimater om arbejdsbelastning baseret på oplysninger, du indsamler fra virksomheden. Det betyder, at du skal stille svære spørgsmål om, hvor meget data de vil forvente i den første måned, de første seks måneder og det første år. Når der kommer en ny løsning, er dette ofte det SIDSTE, virksomheden tænker på, så meget ofte vil du få vage svar. I tilfælde af en ny løsning, skal du virkelig gøre en bedste gæt indsats. Træk ikke dit hår ud for at prøve at få nøjagtige tal.
Hvis løsningen er fra en leverandør, skal du bede leverandøren om planlægningsanbefalinger om både den nødvendige plads og de nødvendige ressourcer. Jeg indrømmer, at de måske ikke har de data, men du får ikke det, du ikke beder om. Det skader aldrig at prøve.
[Bonus:Hvis leverandøren ikke har nogen oplysninger at give, ville det så ikke være nyttigt, hvis du, efter at systemet har været oppe og køre i et par måneder, sender dem dine data...såsom hvilken hardware du har , og hvordan ser arbejdsbyrden ud? Det behøver ikke at være en 20-siders skrive-up, men feedbacken kan skubbe dem i retning af at være mere proaktive fremadrettet.]
Med hensyn til en eksisterende løsning, hvis du har et ydelsesproblem, eller du ønsker at opgradere hardware, vil du gerne indfange oplysninger om det aktuelle miljø for at planlægge et nyt.
Lagring
Planlægning for beløbet det nødvendige lager er ret simpelt, det kræver bare noget planlægning på forhånd. I mine proaktive SQL Server-sundhedstjekartikler diskuterer jeg overvågning af diskplads og inkluderer en forespørgsel for at indfange filoplysninger. Denne forespørgsel fanger størrelsen af databasefilerne for forekomsten såvel som den brugte plads. Det er bydende nødvendigt at trende disse data over tid, og det betyder ikke et par uger. Du søger at se, hvordan filerne ændrer sig over måneder, muligvis i op til et til to år, fordi brugsmønstre for en applikation kan ændre sig. Denne information er nem at fange, kræver lidt plads at opbevare og er uvurderlig at have som reference, når du anskaffer lager. Hvis du kan give kvantitative data om systemets vækst, har du en meget bedre chance for at få den plads, du har brug for, frem for at skulle bede om det senere. Og når du beder om plads, så sørg for at inkludere tempdb i dine beregninger.
Hardwareressourcer
CPU
At optimere din CPU-ydelse handler ikke kun om antallet af CPU'er, du har, du skal også overveje modellen og arbejdsbyrden (f.eks. datavarehus med store parallelle forespørgsler vs. OLTP med serielle forespørgsler). Med disse oplysninger og lidt hjælp fra Glenn kan du bestemme den bedste processor til din server. Glem ikke at overveje licensomkostninger og begrænsninger baseret på din udgave af SQL Server!
Hukommelse
Hukommelse er relativt billig, og det er vores anbefaling altid at købe den maksimale mængde hukommelse, som en server kan rumme. At læse data fra hukommelsen er betydeligt hurtigere end at læse det fra disk, så jo flere data, der passer ind i hukommelsen, jo bedre. Bemærk, at hele databasen ikke har at passe ind i hukommelsen. Du skal bare bruge arbejdsdatasættet for at passe ind i hukommelsen. Overvej en 2TB database. Det er usandsynligt, at der i et OLTP-scenarie er adgang til alle 2TB hver dag. Typisk er der kun adgang til de seneste data – måske kun de sidste 30 eller 60 dage. Det er de data, der skal passe i hukommelsen. Men selvfølgelig ser vi sjældent et rent OLTP-miljø, ofte er det et blandet miljø, fordi brugere kan lide at køre rapporter over store datasæt, og der er intet datavarehus eller rapporterende kopi af databasen, så de har at køre rapporterne mod produktion. Dette komplicerer hukommelseskravet. Nogle gange har du brug for de ældre data i hukommelsen, men nogle gange har du ikke. Det er vigtigt at forstå arbejdsbyrden; hvilke typer forespørgsler udføres mod databasen?
Hvis du bruger Standard Edition, skal du kontrollere, at du har mere hukommelse på serveren end den maksimale understøttede hukommelse. For eksempel, med SQL Server 2014 og højere, i Standard Edition er den maksimale mængde hukommelse, som du kan allokere til bufferpuljen (via den maksimale serverhukommelsesindstilling) 128 GB. Derfor vil du gerne have mere hukommelse i serveren (f.eks. 160GB), så du kan indstille max serverhukommelse til den højest mulige værdi på 128GB, og stadig have hukommelse tilgængelig til OS og andre SQL Server-processer. Yderligere kan du med SQL Server 2016 SP1 Standard Edition bruge In-Memory OLTP med en grænse på 32 GB pr. database. Dette er over den maksimale serverhukommelsesværdi, så hvis du planlægger at bruge denne funktion, skal du købe hukommelse i overensstemmelse hermed.
Opbevaring
Når vi taler om ydeevnekrav til lagring, hører man ofte folk tale om IOPS (input/output operations per second). Faktisk var denne artikel inspireret af et spørgsmål fra en seer, der så mit Pluralsight-kursus om Benchmarking og Baselining. Spørgsmålet var:"Hvordan korrelerer du Performance Monitor-tællerne for læsninger og skrivninger pr. sekund til brugerforbindelser for at estimere antallet af IO'er pr. bruger?" Læsning og skrivning per sekund er input/output-operationerne, så vi har disse data tilgængelige via PerfMon på instansniveau, og det er det, du bruger til at definere IOPS-kravene for en instans.
Men hvis du ved læser og skriver og brugerforbindelser, så kan du lave noget matematik og finde ud af IOPS pr. bruger. Dette er nyttigt, hvis du planlægger at udvide løsningen og tilføje flere brugere. Du vil sikre dig, at løsningen vil skalere, og en mulighed, du har, er at tage din beregnede IOPS pr. bruger, baseret på X antal brugere, og derefter estimere instans IOPS for Y antal brugere. Nu gør vi en masse antagelser med denne beregning. Vi antager, at den måde, nye forbindelser bruger systemet på, er den samme, som det er i dag - det kan eller ikke er tilfældet i sidste ende, det ved du ikke, før systemet er på plads. Når du forstår denne værdi (læser + skriver / brugerforbindelser =gennemsnitlig IOPS pr. bruger), så ved du, hvordan du estimerer IOPS for en løsning baseret på forventede brugerforbindelser.
Du tager derefter disse oplysninger med til din lagerperson for at diskutere de potentielle tilgængelige konfigurationer. Du kan beregne den maksimale IOPS for en diskkonfiguration, forudsat at du har oplysninger om diskene (f.eks. antallet af diske, hastigheden, størrelsen og RAID-konfigurationen). Du kan teste IO-gennemstrømning for et drev ved hjælp af CrystalDiskMark, selvom dette muligvis ikke er muligt, hvis lagringen ikke er besluttet. Når det er på plads, bør du dog gennemgå denne test for at sikre, at IOPS'en for et givet drev kan leve op til den forventede arbejdsbyrde.
IOPS er blot én måde at se på lagerydeevne. Forstå, at disse data fortæller dig, hvor meget IO, der forekommer, og ideelt set, hvis du kender IOPS, og du har lageret til at opfylde kravene, bør latenstiden være minimal. Men latens er det, der påvirker ydeevnen. For at bestemme, hvilken latency der eksisterer, skal du bruge et værktøj som DiskSpd til at benchmarke lageret. Glenn har en fantastisk artikel, der forklarer, hvordan man analyserer IO-ydeevne, og så en anden artikel om, hvordan man bruger DiskSpd til at teste det for at forstå latenstiden. Jeg anbefaler stærkt at gennemgå begge artikler, hvis du ikke tidligere har set på lagerplads og ydeevne.
Konklusion
Kapacitetsplanlægning handler om mere end blot at vide, hvor meget plads du har brug for til databasefiler. Du skal forstå arbejdsbyrden, og hvad den kræver med hensyn til CPU, hukommelse og diskressourcer. For at gøre dette har du brug for data...hvilket betyder, at du skal opfange basislinjer. Min allerførste session i SQL Server-fællesskabet var i december 2010, og det handlede om grundlinjer. Seks år senere taler jeg stadig om deres betydning, og jeg hører stadig fra folk, at de ikke har disse tal. Hvis du vil lave intelligent, målrettet kapacitetsplanlægning, så skal du indsamle de relevante data ... ellers gætter du bare.