Det primära fokus för denna bloggsida är prestanda i en SQL Server-miljö. Man skulle kunna hävda att prestanda börjar med databas- och applikationsdesign. Men du kan också hävda att det är viktigt att ha rätt resurser tillgängliga för god prestation. För all diskussion om rätt resurser (vilken CPU-modell, hur mycket minne, vilken typ av lagring) försummar vi ibland handlingen med kapacitetsplanering:att använda den data vi har att fatta välgrundade beslut om vad vi behöver . Kapacitetsplanering är inte bara att ta reda på hur mycket diskutrymme vi behöver, det involverar också de resurser som en SQL Server-instans måste ha tillgängliga för att hantera arbetsbelastningen.
Ny eller befintlig?
Kapacitetsplanering för en ny lösning är riktigt knepigt. Du måste komma med uppskattningar om arbetsbelastning baserat på information du samlar in från verksamheten. Det betyder att du måste ställa svåra frågor om hur mycket data de kommer att förvänta sig under den första månaden, de första sex månaderna och det första året. När en ny lösning kommer in är detta ofta det SISTA företaget tänker på, så väldigt ofta kommer du att få vaga svar. När det gäller en ny lösning måste du verkligen göra en bästa gissningsinsats. Dra inte ut håret för att försöka få exakta siffror.
Om lösningen kommer från en leverantör måste du be leverantören om planeringsrekommendationer om både utrymme som behövs och de resurser som behövs. Jag erkänner att de kanske inte har den informationen, men du får inte det du inte ber om. Det skadar aldrig att försöka.
[Bonus:Om leverantören inte har någon information att tillhandahålla, skulle det inte vara till hjälp om du, efter att systemet har körts i några månader, skickar dem dina data...som vilken hårdvara du har , och hur ser arbetsbelastningen ut? Det behöver inte vara en 20-sidig skrivelse, men feedbacken kan föra dem i riktning mot att vara mer proaktiva framöver.]
När det gäller en befintlig lösning, om du har ett prestandaproblem eller om du vill uppgradera hårdvara, vill du samla information om den aktuella miljön för att planera för en ny.
Lagring
Planerar för beloppet lagring som behövs är ganska enkel, det kräver bara lite planering i förväg. I mina proaktiva SQL Server-hälsokontrollartiklar diskuterar jag övervakning av diskutrymme och inkluderar en fråga för att fånga filinformation. Den här frågan fångar storleken på databasfilerna för instansen samt det utrymme som används. Det är absolut nödvändigt att trenda dessa data över tid, och det betyder inte några veckor. Du vill se hur filerna förändras under månader, möjligen i upp till ett till två år, eftersom användningsmönster för en applikation kan ändras. Denna information är lätt att fånga, kräver lite utrymme att lagra och är ovärderlig att ha som referens när du ska skaffa lagring. Om du kan tillhandahålla kvantitativa data om systemets tillväxt har du en mycket bättre chans att få det utrymme du behöver i förväg snarare än att behöva be om det senare. Och när du ber om utrymme, se till att inkludera tempdb i dina beräkningar.
Hårdvaruresurser
CPU
Att optimera din CPU-prestanda handlar inte bara om antalet CPU:er du har, du måste också ta hänsyn till modellen och arbetsbelastningen (t.ex. datalager med stora parallella frågor kontra OLTP med seriella frågor). Med denna information, och lite hjälp från Glenn, kan du bestämma den bästa processorn för din server. Glöm inte att överväga licenskostnader och begränsningar baserat på din utgåva av SQL Server!
Minne
Minne är relativt billigt och det är vår rekommendation att alltid köpa den maximala mängden minne som en server kan hålla. Att läsa data från minnet är betydligt snabbare än att läsa det från disk, så ju mer data som får plats i minnet desto bättre. Observera att hela databasen inte har att passa i minnet. Du behöver bara den fungerande uppsättningen av data för att passa in i minnet. Överväg en 2TB databas. Det är osannolikt att, i ett OLTP-scenario, alla 2 TB nås varje dag. Vanligtvis nås bara senaste data – kanske bara de senaste 30 eller 60 dagarna. Det är den data som måste få plats i minnet. Men naturligtvis, sällan ser vi en ren OLTP-miljö, ofta är det en blandad miljö eftersom användare gillar att köra rapporter över stora uppsättningar data, och det finns inget datalager eller rapporterande kopia av databasen så de har> att köra rapporterna mot produktionen. Detta komplicerar minneskravet. Nu behöver du ibland äldre data i minnet, men ibland inte. Det är viktigt att förstå arbetsbelastningen; vilka typer av frågor körs mot databasen?
Om du använder Standard Edition kontrollera att du har mer minne på servern än det maximala minne som stöds. Till exempel, med SQL Server 2014 och högre, i Standard Edition är den maximala mängden minne som du kan allokera till buffertpoolen (via inställningen för max serverminne) 128 GB. Därför vill du ha mer minne i servern (t.ex. 160GB) så att du kan ställa in max serverminne på högsta möjliga värde på 128GB, och fortfarande ha minne tillgängligt för OS och andra SQL Server-processer. Med SQL Server 2016 SP1 Standard Edition kan du dessutom använda In-Memory OLTP, med en gräns på 32 GB per databas. Detta är över det maximala serverminnesvärdet, så om du planerar att använda den här funktionen, köp minne i enlighet med detta.
Lagring
När vi pratar om prestandakrav för lagring hör man ofta folk prata om IOPS (input/output operations per second). Faktum är att den här artikeln var inspirerad av en fråga från en tittare som tittade på min Pluralsight-kurs om benchmarking och baslinje. Frågan var:"Hur korrelerar du Performance Monitor-räknare för läsningar och skrivningar per sekund till användaranslutningar för att uppskatta antalet IO per användare?" Läsning och skrivning per sekund är in-/utdataoperationerna, så vi har denna data tillgänglig via PerfMon på instansnivå, och det är detta du använder för att definiera IOPS-kraven för en instans.
Men om du vet läser och skriver och användaranslutningar, då kan du göra lite matematik och räkna ut IOPS per användare. Detta är användbart om du planerar att utöka lösningen och lägga till fler användare. Du vill vara säker på att lösningen kommer att skalas, och ett alternativ du har är att ta din beräknade IOPS per användare, baserat på X antal användare, och sedan uppskatta instans IOPS för Y antal användare. Nu gör vi många antaganden med denna beräkning. Vi antar att sättet som nya anslutningar använder systemet på är detsamma som det är idag – det kan eller kanske inte är fallet i slutändan, du vet inte förrän systemet är på plats. När du förstår detta värde (läser + skriver/användaranslutningar =genomsnittlig IOPS per användare), då vet du hur man uppskattar IOPS för en lösning baserat på förväntade användaranslutningar.
Du tar sedan med dig denna information till din lagringsperson för att diskutera möjliga tillgängliga konfigurationer. Du kan beräkna maximal IOPS för en diskkonfiguration, förutsatt att du har information om diskarna (t.ex. antalet diskar, hastigheten, storleken och RAID-konfigurationen). Du kan testa IO-genomströmningen för en enhet med CrystalDiskMark, även om detta kanske inte är möjligt om lagringen inte har bestämts. När den väl är på plats bör du dock gå igenom detta test för att säkerställa att IOPS för en viss enhet kan möta den förväntade arbetsbelastningen.
IOPS är bara ett sätt att se på lagringsprestanda. Förstå att denna data talar om för dig hur mycket IO som förekommer, och helst, om du känner till IOPS och du har lagringen för att uppfylla kraven, bör latensen vara minimal. Men latens är det som påverkar prestandan. För att avgöra vilken latens som finns måste du använda ett verktyg som DiskSpd för att benchmarka lagringen. Glenn har en bra artikel som förklarar hur man analyserar IO-prestanda, och sedan en annan artikel om hur man använder DiskSpd för att testa det för att förstå latensen. Jag rekommenderar starkt att du granskar båda artiklarna om du inte har tittat på lagring och prestanda tidigare.
Slutsats
Kapacitetsplanering handlar om mer än att bara veta hur mycket utrymme du behöver för databasfiler. Du måste förstå arbetsbelastningen och vad den kräver i form av CPU, minne och diskresurser. För att göra detta behöver du data ... vilket betyder att du behöver fånga baslinjer. Min allra första session i SQL Server-communityt var i december 2010, och det handlade om baslinjer. Sex år senare pratar jag fortfarande om deras betydelse, och jag hör fortfarande från folk att de inte har dessa siffror. Om du vill göra intelligent, målinriktad kapacitetsplanering måste du samla in lämplig data ... annars gissar du bara.