Utför en prestandaanalys av din SQL Server #2
Förord
Hur du använder Performance Monitor för identifiering av flaskhalsar i SQL Serverns hårdvara
av Brad M. McGee
Checklista för prestandaanalys
Skriv in dina resultat i tabellen ovan.
Använd Performance Monitor för identifiering av flaskhalsar i SQL Serverns hårdvara
Det bästa stället att börja på när du ska utföra en prestandaanalys är genom att använda din Performance Monitor (System Monitor). Genom att övervaka några grundläggande Counters under 24 timmar, så kan du få en ganska bra översikt över de eventuella flaskhalsar som din SQL Server kan ha råkat ut för. Det idealiska vore om du använde Performance Monitor för att skapa en loggfil med Countrar, över en period på 24 timmar. Du bör välja en ”typisk” 24-timmars period när du skapar loggfilen, t ex en vanlig arbetsdag – inte någon helg eller semesterdag.
När du har samlat ihop dina 24-timmars Performance Monitor data i en loggfil, så använder du Graph Mode i Performance Monitor för att kontrollera de ovan rekommenderade Countrarna. Därefter fyller i värdena för genomsnitt, minimum och maximum i tabellen längst upp på sidan. När du har gjort det så kan du jämföra resultaten med analyserna nedan. Genom att jämföra dina resultat med rekommendationerna nedan, så kan du snabbt identifiera eventuella flaskhalsar som din SQL Server hårdvara råkar ut för.
Hur du tolkar dina Performance Monitor Counters
Nedan följer diskussioner om olika Performance Monitor Counters, dess rekommenderade värden, samt några alternativ som kan hjälpa dig identifiera och lösa flaskhalsar i hårdvaran. Notera att jag har valt att övervaka ett begränsat antalet Performance Monitor Counters, och jag har gjort det eftersom målet med den här artikeln är att finna de lätta och uppenbara prestandaproblemen. Du kan finna fler Performance Monitor Counters Memory: Pages/sec
Den här Countern mäter antalet sidor per sekund som hämtas från RAM till hårddisken, eller läggs in i RAM till minnet från hårddisken. Ju mer paging som sker, desto mer I/O belastning råkar Servern ut för, vilket i sin tur kan leda till sämre prestanda i SQL Servern.
Förutsatt att SQL Server är den enda stora applikationen som körs på din Server, så ska det genomsnittliga värdet du får här ligga runt 0 under en 24-timmarsperiod (med undantag för enskilda toppar, vilket är normalt). Om så inte är fallet, och om det genomsnittliga värdet är större än 1 men mindre än 20, så bör du ändå inte märka någon särskild reducering av din SQL Server prestanda. Skulle Countern dock överstiga genomsnittet 20 över en 24-timmarsperiod, så är det högst troligt att din Server behöver mer RAM minne. Ju mer RAM minne en Server har, desto mindre paging sker det.
För en fysisk Server, som endast är avsedd för SQL Server, och som har tillräckligt med RAM minne, bör genomsnittet generellt sett ligga på noll. En tillräcklig mängd RAM för SQL Server, är en Server där Buffer Hit Cache Ratio (förklaras i detalj senare) ligger på 99 % eller högre. Om du har en SQL Server där Buffer Hit Cache Ratio ligger på 99 % eller högre under en 24-timmars period, men som ändå får en genomsnittlig pagingnivå på över 1 under samma period, så kan det betyda att du kör fler applikationer än SQL Server på din fysiska Server. Om så är fallet så bör du ta bort dem andra applikationerna och låta SQL Server vara den enda stora applikationen som körs på din fysiska Server.
Om en Servern inte kör fler applikationer än SQL Server, och om pagingen ändå överskrider 1 under en 24-timmars period, så kan det bero på att du har ändrat SQL Server minnets inställningar. SQL Serverns konfigureringar bör vara satta till ”Dynamically configure SQL Server Memory”, och inställningen ”Maximum Memory” bör vara satt till den högsta nivån. För optimal prestanda bör SQL Servern vara tillåten att ta så mycket minne den behöver, utan att behöva konkurrera med andra applikationer om RAM minnet.
Memory: Available Bytes
En annan metod du kan använda för att se så att din SQL Server har tillräckligt med fysisk RAM, är genom att kontrollera Memory Object: Available Bytes Countern. Det värdet du får här bör vara större än 5 MB. Om det inte är det, så behöver din SQL Server mer fysisk RAM. På en Server som är hängiven till SQL Server, så försöker SQL Server att tillhandahålla mellan 4-10 MB ledigt fysiskt minne. Det fysiska RAM som blir över används utav operativsystemet och SQL Server. Då mängden tillgängliga bytes understiger 5 MB, så är det högst troligt att din SQL Server upplever ett slag i prestandan på grund av för lite minne. När det händer så måste du antingen öka mängden fysisk RAM i din Server, eller reducera lasten i din Server, eller göra lämpliga ändringar i SQL Serverns minneskonfiguration.
Physical Disk: % Disk Time
Den här Countern mäter hur upptagen en fysisk array är (alltså inte någon logisk partition eller någon individuell disk i arrayen). Det ger dig en relativt bra uppfattning om hur upptagen din array är. En tumregel är att % Disk Time Countern bör köras under 55 %. Om Countervärdena överstiger 55 % under en kontinuerlig period (över t ex 10 minuter under en 24-timmars övervakningsperiod), så kan det vara så att din SQL Server har råkat ut för en flaskhals i I/O. Om du ser det här beteendet en enda gång under en 24-timmars övervakningsperiod, så behöver du inte oroa dig. Men om det skulle hända ofta, så skulle jag börja leta efter olika sätt att höja Serverns I/O prestanda. Några saker man kan göra för att höja disk I/O är att lägga till extra diskar i arrayen (om du kan), skaffa snabbare hårddiskar, lägg till extra cacheminne till controllerkortet (om du kan), använd en annan RAID version, skaffa snabbare controller eller reducera lasten på Servern.
Innan du använder den här Countern under Windows NT 4.0 så måste du dra igång den manuellt genom att skriva ”diskperf -y” i NTs kommandoprompt, och sedan starta om datorn. Detta krävs du göra då du ska dra igång den här disk Countern för första gången. Om du kör Windows 2000 så sätts den här Countern igång som standard.
Physical Disk: Avg. Disk Queue Length
Förutom att kolla Physical Disk: % Disk Time Countern, så bör du även kolla Physical Disk: Avg. Disk Queue Length Countern. Om det värdet du får här överstiger 2 för varje hårddisk i en diskarray, under en kontinuerlig period (över t ex 10 minuter under en 24-timmars övervakningsperiod), så har du förmodligen en flaskhals i I/O i den diskarrayen. Precis som med Physical Disk: % Disk Time Countern, så om det skulle överstiga 2 en gång under en 24-timmars övervakningsperiod, så behöver du inte oroa dig. Men om det händer flera gånger, så bör du överväga vissa alternativ för att öka I/O prestandan på Servern, precis som jag beskrev tidigare.
Du måste kanske sen utföra vissa beräkningar med dessa värden, eftersom Performance Monitor inte vet hur många fysiska diskar du har i en array. Om du t ex har en array med 6 fysiska diskar, och om Physical Disk: Avg. Disk Queue Length Countern ger dig värdet 10 över den arrayen, så är det faktiska Avg. Disk Queue Length för varje hårddisk i arrayen 1,66 (10/6) – vilket ligger inom gränsen på 2 per fysisk disk.
Innan du använder den här Countern under Windows NT 4.0 så måste du dra igång den manuellt genom att skriva ”diskperf -y” i NTs kommandoprompt, och sedan starta om datorn. Detta krävs du göra då du ska dra igång den här disk Countern för första gången. Om du kör Windows 2000 så sätts den här Countern igång som standard.
Process Object: % Processor Time
Process Object: % Processor Time Countern är tillgänglig för varje enskild CPU (instans), och mäter förbrukningen av varje individuell CPU. Den är också tillgänglig för alla CPUn (totalt). Det här är huvudcountern för att se över CPU förbrukningen. Om % Total Processor Time Countern (totalt) överskrider värdet 80 % under en kontinuerlig period (över t ex 10 minuter under en 24-timmars övervakningsperiod), så har du förmodligen en flaskhals i CPUn. Om dessa sysselsatta perioder bara uppstår lite då och då och om du kan leva med det, så är det OK. Men om de inträffar ofta, så bör du överväga att minska lasten på Servern, skaffa snabbare CPUn, skaffa fler CPUn eller skaffa CPUn som har en större L2 cache.
System: Processor Queue Length
Tillsammans med Process Object: % Processor Time Countern, så bör du också övervaka Processor Queue Length Countern. Om det värdet överskrider 2 under en kontinuerlig period (över t ex 10 minuter under en 24-timmars övervakningsperiod), så har du förmodligen en flaskhals i CPUn. Så om du t ex har 4 CPUn i din Server, så bör Processor Queue Length Countern inte överskrida 8 för hela Servern.
Om Processor Queue Length Countern överskrider det rekommenderade maximumvärdet regelbundet, trots att inte CPU förbrukningen verkar vara hög (vilket är vanligt), så bör du överväga att sänka SQL Serverns ”max worker threads” i konfigurationsinställningarna. Det är nämligen möjligt att Processor Queue Length ger höga värdena därför att det finns ett mängd arbetetsuppgifter som står och väntar på att de ska få köras igång. Genom att reducera antalet ”maximum worker threads” så tvingar du din threads pooling att köra igång (om det inte redan är igång), eller att ta större fördel av threads poolingen.
Använd både Processor Queue Length och % Total Process Time då du letar efter flaskhalsar i CPUn. Om båda Countrarna överskrider de rekommenderade värdena under samma kontinuerliga period, så kan du vara säker på att du har en flaskhals i CPUn.
SQL Server Buffer: Buffer Cache Hit Ratio
Buffer Cache Hit Ratio Countern indikerar på hur ofta din SQL Server går till Buffern, och inte till hårddisken, då den vill hämta ut data. I OLTP applikationer bör den här kvoten överskrida 90 %, och det idealiska vore om den låg över 99 %. Om Buffer Cache Hit Ration understiger 90 % så bör du gå ut och köpa in mer RAM redan idag. Om kvoten ligger mellan 90-99 % så bör du allvarligt överväga att införskaffa mer RAM. Ju närmare 99 % kvoten ligger, desto snabbare kommer din SQL Servers att fungera. I vissa fall då din databas är enormt stor, så kan det vara omöjligt att komma upp i 99 %, även om du slänger i maximalt med RAM i din Server. Allt du kan göra är att lägga till så mycket RAM det går, och sedan leva med det.
I OLAP applikationer kan kvoten vara avsevärt mycket mindre, med tanke på hur OLAP applikationer fungerar. I vilket fall som helst så ger extra fysiskt RAM minne ökad prestanda i SQL Servern.
SQL Server General: User Connections
Eftersom antalet användare som använder din SQL Server kan påverka dess prestanda, så bör du hålla ett öga på SQL Server General Statistics Object: User Connections Countern. Den påvisar antalet användaranslutningar (inte antalet användare) som är uppkopplad mot SQL Servern för tillfället.
Om den här Countern överskrider 255, så bör du höja ”Maximum Worker Threads” siffran till något högre än standardinställningen 255. Om antalet anslutningar överskrider antalet tillgängliga ”Worker Threads”, så kommer SQL Servern att dela på trådarna, vilket kan skada prestandan. Inställningen för ”Maximum Worker Threads” bör inte överstiga det maximala antalet användaranslutningar som din Server någonsin kommer upp i.
0 Kommentarer