SQL Server Performance Trend Analysis del #4
Förord
Det här är del fyra i en artikelserie på fyra delar. Den här artikeln kommer att behandla ämnet om hur du ska tyda de vanligaste Counters från NT Server och SQL Server Performance Monitor.
I de föregående tre delarna har du lärt dig använda Performance Monitor till att samla in SQL Server relaterade prestandadata, att lagra det i din SQL Server och hur du genomför trendanalyser med hjälp av dina data. Nu ska vi alltså titta på hur du ska tolka resultaten.
Det spelar för den här artikeln ingen roll vart du tittar på dina Performance Monitor Data. Det kan vara i själva Performance Monitor, i Microsoft Excel eller vilket annat program som helst. Allt du behöver göra är att komma åt resultaten. När du tolkar dina resultat så spelar det ingen roll i vilket format du gör det.
Innehåll
»»
»
»
»
»
»
Relaterade artiklar
» SQL Server Performance Trend Analysis del #1» SQL Server Performance Trend Analysis del #3
» SQL Server Performance Trendanalys del #2
SQL Server Prestanda Analysering
Del 4: Interpreting Performance Monitor Counters
Skribent: Brad M. McGehee
Trots att vårt huvudfokus i den här artikeln ligger i SQL Serverns prestanda, så måste vi komma ihåg att operativsystemet (oavsett om det är Windows NT Server 4.0 eller Windows 2000) är hoptvinnat med SQL Server, speciellt när det handlar om poster från Performance Monitor. Faktum är att då jag övervakar SQL Serverns prestanda, så blir det ofta att jag övervakar fler Counters i operativsystemets än vad jag gör av dem i SQL Server. Detta därför att några av de viktigaste prestandaposterna ligger i operativsystemet, inte i SQL Servern. Håll det på minnet när vi senare i artikeln går igenom hur du tolkar prestanda utifrån de varierande Counters som finns.
Som du kanske vet så har Windows NT Server 4.0 och Windows 2000 över 350 åtkomliga Counters för Performance Monitor prestandadata. SQL Server 7.0 och SQL Server 2000 har båda över 100 åtkomliga Counters för Performance Monitor data. Antalet Counters för potentiella prestandarelaterade data må vara överväldigande, men som tur är övervakar du sällan allihopa av dem. Generellt sett brukar jag endast övervaka ett dussintal Counters regelbundet, men då jag vill söka efter ett specifikt prestandarelaterat problem så kan det hända att jag övervakar fler. I den här artikeln kommer vi att fokusera oss på de huvudsakliga prestandaposterna.
Fokusera dig på den Stora Bilden
När jag övervakar SQL Server med hjälp av Performance Monitor så är mitt mål att fånga in helheten, inte detaljerna. Om helheten däremot indikerar på att jag bör ta en närmare till på detaljerna, så visst, men om inte, så har jag bättre saker att spendera min tid på. Det som den Stora Bilden låter mig se är hur min SQL Server mår, och det är därför som jag bara övervakar dussintalet Counters från Performance Monitor, vilka kommer att diskuteras nedan. Som så många andra så använder jag mig utav Performance Monitor till att leta efter potentiella flaskhalsar i prestandan, vilka oftast finns under följande fem kategorier:
CPU: SQL Server kan inte arbeta om det har tagit slut på CPU cykler, så det är viktigt att leta efter potentiella flaskhalsar där.
Minnen: Om du vill ha maximal SQL Server prestanda få får du absolut inte ha flaskhalsar i serverns minne. Visst, operativsystemet kan kolla om det finns nog med fysisk RAM i servern, men vill du verkligen vänta så länge?
I/O: Av alla potentiella flaskhalsar i prestandan så är nog flaskhalsar i disk I/O de svåraste att reda ut. Och precis som att inte ha nog med fysisk RAM så påverkar det SQL Serverns prestanda negativt.
Nätverk: Det här är nog den flaskhals som du behöver bekymra dig minst om, eftersom många Servrar idag knappt kan med att fylla en 100 Mb nätverksanslutning, hur de än försöker.
Själva SQL Servern: Detta inkluderar en mängd olika SQL Server Counters som du kan övervaka för att hjälpa dig identifiera de olika potentiella prestandarelaterade problemen i SQL Servern.
I de följande avsnitten kommer vi att diskutera varje ovanstående möjlighet till flaskhals lite närmare, för att sedan titta på de olika Performance Monitor Counters som kan hjälpa oss identifiera dem. Vi kommer också att titta på hur du tolkar resultaten och hur du reder ut flaskhalsarna.
Counters för CPU Performance Monitor
Att mäta CPU aktiviteten på din SQL Server är en nyckelväg till att identifiera eventuella flaskhalsar i CPUn. Processobjektet: % Processor Time- Countern är åtkomlig för varje CPU (kommando), och mäter förbrukningen från varje individuell CPU. Trots att det kan vara användbart att kunna se över aktiviteten för varje CPU i Servern, så brukar jag generellt sett bara vilja övervaka helheten för hela CPU aktiviteten på Servern. Detta gör jag med en annan Counter, vilken jag kommer att visa mer på i nästa stycke. Om du har flera CPUn på din Server och om du använder ovanstående Counter för att övervaka var och en, så kommer du att märka att varje CPU är upptagen vid olika tillfällen. Oroa dig inte över det bara. Trots att operativsystemet gör allt den kan för att fördela arbetslasten jämnt över varje CPU, så är det i verkligheten en process som är under utveckling, vilket leder till att vissa CPUn kan komma att jobba mer än andra. Processobjektet: % TOTAL Processor Time countern mäter genomsnittet över alla CPUn i din Server. Det här är den viktigaste Countern till att övervaka förbrukningen av CPUn. Om din % TOTAL Processor Time counter överskrider 80 % under kontinuerliga perioder (över 10 minuter eller liknande), så finns risken att du har en flaskhals på servern. Om det skulle uppstå en tillfällig pik på över 100 % så behöver du inte oroa dig, för det är ett normalt beteende för de flesta SQL Servrarna.
Ovanstående Counter är också användbar då du ska utföra trendanalyser. Om du t ex märker att % TOTAL Processor Time countern för tillfället faktiskt befinner sig inom gränserna, men att värdena ökar månad efter månad, så kan det vara en vink om att din server eventuellt kommer att få slut på CPU cykler inom kort. Om du upptäcker det problemet nu så blir det lättare att planera in i framtiden.
Trots att % TOTAL Processor Time countern är viktig, så litar jag inte gärna på att det räcker med att en enda Counter indikerar på flaskhalsar på Servern. Då finns det en annan värdefull mätare på CPU prestanda, och det är Systemobjektet Processor Queue Length. Om Processor Queue Length överskrider 2 per CPU under en kontinuerlig period (över 10 minuter eller liknande), då har du förmodligen problem med flaskhalsar i CPUn. Om du alltså har t ex 4 CPUn i din server, så bör inte Processor Queue Length överskrida 8 för hela servern.
Använd både % TOTAL Processor Time och Processor Queue Length countrarna då du letar efter flaskhalsar i CPUn. Om båda Counters överskrider de rekommenderade värdena under samma perioder, så har du försäkrat dig om att det verkligen är en flaskhals i CPUn som du har att göra med.
Om din Processor Queue Length regelbundet överskrider de rekommenderade värdena och om förbrukningen av CPU inte är särskilt hög (vilket är vanligt), så bör du överväga möjligheten att sänka SQL Serverns ”max worker threads” i konfigurationsinställningarna. Det är nämligen möjligt att värdena som Processor Queue Length visa på är höga därför att det finns ett stort antal 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.
Låt säga att din SQL Server har råkat ut för flaskhalsar. Testa då följande saker för att försöka lösa problemen:
- Skaffa snabbare eller extra CPUn
- Skaffa CPUn med ett större L2 cache
- Gör om din applikation så att den inte behöver komma åt hårddisken lika ofta. Du kan t ex skapa Index för att slippa en genomsökning av hela tabellen, eller gör om din databas så att den eliminerar överbliven data, osv.
- Gör om dina SQL-satser så att de inte belastar CPUn
- Flytta några av processlasterna till en annan SQL Server
- Överväg möjligheten att sätta på Windows NT fiber (Endast för SQL Server 7.0 och 2000)
- Försäkra dig om att det inte körs SQL-satser mot både OLAP och OLTP på en och samma server. Dessa två databas applikationer bör skötas från två olika servrar.
Counters för I/O prestanda
Om ditt I/O subsystem fungerar som det ska så behöver inte SQL Server vänta med att skriva eller läsa data. Men om lasten på din Server är för stor så kan den inte både läsa och skriva samtidigt, utan de får turas om. Detta kan reducera prestandan.Det bästa sättet att se detta på är genom att övervaka Physical Disk Object: Avg. Disk Queue Length, som övervakar varje diskarray i din server. Om din Avg. Disk Queue Length för varje disk i en array överskrider 2 under en kontinuerlig period (över en 10 minuters period t ex), så har du säkert en I/O flaskhals i den diskarrayen. Du måste kanske sen utföra vissa beräkningar enligt denna figur, eftersom Performance Monitor inte vet hur många fysiska diskar du har i en array.
Säg t ex att du har en array med 6 fysiska diskar, och att din Avg. Disk Queue Length indikerar på 10 över den arrayen, så är det egentliga värdet för varje disk i arrayen 0,83 (10/12 = 0,83). Detta är då alltså acceptabelt, eftersom den inte fick överskrida 2 för varje fysisk disk.
Det fysiska diskobjektet: % Disk Time countern är, på grund av flera anledningar, också ett användbart verktyg. Den här metoden mäter arbetsnivån i en fysisk array (alltså inte logiska partitioner eller individuella diskar i en array). Den tillgodoser dig med information om hur upptagen arrayen är, och den kan efter mätning under särskilda tidsperioder hjälpa dig finna indikeringar på ett ökande behov av I/O på din server, och visa på hur stort behovet kan vara i framtiden.
En bra tumregel att följa är att din % Disk Time- counter inte bör överskrida 55 % efter en mätning under en kontinuerlig period (t ex över 10 minuter). Om den gör det så kan din SQL Server ha råkat ut för en I/O flaskhals. Och om du misstänker att du har en flaskhals på en fysisk disk så kan du använda dig utav de fysiska diskobjekten: % Disk Read Time och % Disk Write Time counters, för att på så sätt bestämma huruvida flaskhalsen har skapats genom läsningar eller skrivningar.
Ovanstående counter är också bra då du vill få reda på hur arbetslasten över varje array på din server är. Genom att övervaka varje array så kan du se hur din I/O balanseras över varje. Generellt sett så bör du se till så att SQL Serverns I/O last är så välbalanserad över arrayerna som möjligt, och genom att använda denna counter så kan du se hur väl du har lyckats med det. Om du upptäcker att en array är mer upptagen än någon annan, så bör du överväga alternativet att flytta filer från den högt sysselsatta arrayen till en mindre sysselsatt array.
Innan du använder någon counter för Windows NT 4.0 så måste du manuellt dra igång dem genom att gå till NTs kommandoprompt och skriva ”diskperf -y” och sedan starta om datorn. Detta måste du göra då du ska dra igång någon counter för första gången.
Om din SQL Server har råkat ut för I/O flaskhalsar, överväg då följande lösningar:
- Lägg till extra fysisk RAM så att din server kan utnyttja RAM istället för I/O då den behöver komma åt data.
- Om du inte redan gör det, använd RAID 5 eller RAID 10 till dina arrayer. RAID 10 är den snabbaste av dem RAIDer som stöder redundans.
- Lägg till extra fysiska diskar i din array. Det hjälper till att öka möjligheten att komma åt dina data då du vill läsa eller skriva. Men lägg inte till fler diskar i din array än vad din I/O controller stöder.
- Byt ut dina nuvarande hårddiskar till snabbare diskar.
- Lägg till snabbare eller extra I/O controllers. Överväg också att lägga till extra cache till de nuvarande controllerna.
- Gör om din applikation så att den inte behöver komma åt hårddisken lika ofta. Du kan t ex skapa Index för att slippa en genomsökning av hela tabellen, eller gör om din databas så att den eliminerar överbliven data, osv.
- Flytta databasen eller transaktionsloggar från en högt sysselsatt array till en mindre sysselsatt array.
- Lagra dina databaser och transaktionsloggar i en SAN (Storage Area Network).
- Använd bara partitionerade vyer och hopkopplade servrar då du vill distribuera arbetslasten (gäller endast för SQL Server 2000).
Counters för minnesprestanda
Detta avsnitt räknar med att din server är hängiven till SQL Server och kanske till några tillhörande server funktioner. Om inte, och om du har några minnesrelaterade prestandaproblem på din SQL Server, så bör det första du gör vara att flytta alla icke-SQL-server relaterade program från den fysiska server där SQL Server körs. När du har gjort det så kan du börja med att leta efter minnesrelaterade flaskhalsar på din SQL Server.En av de nyckel-counters du regelbundet bör övervaka är Minnesobjektet: Pages/Sec. Denna räknar det antalet sidor per sekund som plockas ut från minne till disk, eller som läggs in i minnet från disken. Om vi antar att SQL Server är den enda stora applikationen som körs på din server så borde genomsnittet här ligga nära noll, bortsett från tillfälliga toppar vilket är normalt.
Under en kontinuerlig period (t ex 10 minuter) bör alltså genomsnittet ligga runt noll (med en viss aktivitet). Om så inte är fallet innebär det att din Windows NT är tvungen att ”page” data, och det ska den inte göra. Detta därför att SQL Servern inte använder sig utav Windows NTs pagefil, och eftersom SQL Server ska vara den enda stora applikationen som körs på en server så ska det egentligen inte ske så mycket paging.
Om det däremot sker paging regelbundet så innebär det antingen att du kör andra applikationer på Servern som gör att Windows NT får skriva in data, eller så har du konfigurerat SQL Serverns inställningar i Max Server Memory till någonting annat än ”Dynamisk konfiguration av SQL Server Memory”. Försök hitta vart felet ligger och återgälda det, därför att pagingen påverkar SQL Serverns prestanda. Du kan till och med vara tvungen att ta bort de NT applikationer som skapar pagingen.
Om du har konfigurerat om inställningarna i SQL Serverns Max Server Memory till någonting annat än ”Dynamisk konfiguration av SQL Server Memory” så bör du välja tillbaka till denna inställning. Din SQL Server ska ha möjligheten att själv ställa in hur mycket RAM den behöver, utan att behöva konkurrera om RAMen med andra applikationer.
Ett annat sätt att kontrollera ifall din SQL Server har tillräckligt med fysisk RAM är att se över Minnesobjektet: Available Bytes Counter. Denna counter kan du övervaka från Performance Monitor eller genom Windows NT Serverns – eller Windows 2000s – Task Manager (se under Prestandafliken). Detta värdet bör överstiga 5 Mb, annars behöver din SQL Server mer fysisk RAM. På en server som är avsedd för SQL Server, så försöker din SQL Server att hålla minst 4-10 Mb av det fysiska minnet ledigt. Resterande fysiskt minne används av operativsystemet och SQL Servern. Om mängden lediga bytes understiger 4 Mb, så försöker SQL Servern också att utföra paging (vilket den inte ska), och det resulterar i sämre prestanda.
Om din SQL Server råkar ut för flaskhalsar i minnet, se då över följande lösningar:
- Lägg till mer fysisk RAM. Men om du redan har 2 Gb fysiskt RAM bör du kanske istället överväga att uppgradera till antingen SQL Server 7.0 Enterprise Edition (som stöder upp till 3 Gb) eller till SQL 2000 Enterprise Edition (som i teorin stöder upp till 64 Gb RAM minne).
- Försäkra dig om att den enda applikationen som körs på din Server är SQL Server (bortsett från vissa Management program).
- Ta bort eller koppla bort onödiga tjänster.
- Försäkra dig om att din SQL Server körs som en medlemsserver och inte som en domänkontrollant.
- Konfigurera din SQL Server till att allokera minnen dynamiskt (standard) istället för att hårdkoda fasta värden för hur mycket RAM minne SQL Servern ska allokera.
Counters för nätverksprestanda
Ett av de bästa sätten att söka efter flaskhalsar i nätverket på är genom att övervaka nätverkets Interface Object: Total Bytes/Sec Countern. Denna countern mäter antalet bytes som skickas fram och tillbaka mellan servern och nätverket. Det inkluderar både all SQL Server trafik och all icke-SQL Server trafik över nätverket. Om vi antar att din Server endast är avsedd för SQL Server, så borde den absoluta majoriteten av den avlästa trafiken över nätverket orsakas av SQL Server. Det finns inga strikta eller korrekta begränsningar du bör hålla dig inom, eftersom du avläser den faktiska trafiken och inget annat. För att då kunna se om din server har någon flaskhals på nätverket, så kan du jämföra värdet du får fram genom countern med värdet på hur mycket trafik din nätverksanslutning stöder på din SQL Server. Du kan också använda denna counter till att övervaka tiden. Det är viktigt att du är medveten om ifall din nätverkstrafik ökar regelbundet. Om det skulle göra det, så kan du använda denna information till att göra en plan för framtida resurser.
Om din SQL Server skulle råka ut för flaskhalsar på nätverket, se över följande lösningar:
- Lägg till snabbare nätverkskort
- Lägg till extra nätverkskort
- Serverns nätverkskort bör vara kopplad till Switchar
- Nätverkskort bör köras i full-duplex mode
- Gör om din applikation så att den inte behöver färdas onödigt mycket över nätverket. Gör det genom att bara låta den returnera just den data som behövs samt lagrade procedurer.
- Ta bort alla onödiga nätverksprotokoll från din server
- Använd TCP/IP på servrar och klienter
Innan du kan använda Counters för nätverksprestanda på din server så måste du installera Network Monitor Agent på servern. Och när du har installerat det så måste du starta om datorn. Glöm inte heller att köra om NT senaste servicepack för att uppdatera filer som lades in under installationsprocessen.
Counters för SQL Serverns prestanda
Fram tills nu har vi fokuserat på att identifiera och lösa problemen med hårdvarurelaterade flaskhalsar. Men i det här avsnittet ska vi ta en titt på de Performance Monitor Counters som du kan använda då du vill identifiera specifika prestandaproblem i din SQL Server. En av de viktigaste Performance Monitor Countern i SQL Server att övervaka är ”The SQL Server Buffer Manager Object: Buffer Cache Hit Ratio”. Den indikerar på hur många gånger som SQL Server går till bufferten istället för hårddisken när den ska hämta data. I en OLTP applikation bör den kvoten överskrida 95 % vid en regelbunden användning. Om det inte gör det bör du införskaffa extra RAM minne till servern för att öka prestandan. I OLAP applikationer däremot bör den kvoten vara avsevärt mycket mindre, med tanke på hur OLAP applikationer fungerar. Hur som helst så kan extra fysiskt RAM minne öka SQL Serverns prestanda, oavsett om det är OLAP eller OLTP applikationer som körs.
Om du vill veta hur mycket fysiskt RAM minne som är avsett för SQL Serverns cache, så kan du övervaka ”The SQL Server Buffer Manager Object: Cache Size (i sidor)”. Siffran här refereras till antalet sidor, så du bör ta den siffran och multiplicera med 8K (8 192) för att få bestämma hur många kB RAM den tar upp. Generellt sett – om vi antar att din server endast är avsedd som SQL Server – så bör den senare siffran nästan komma upp i den mängd RAM som finns på din server. Siffran ska nästan komma upp i samma mängd RAM som i din dator, men det ska vara mindre än den mängd RAM som används av NT, SQL Server, eller vilket annat program som helst som körs på servern. Om mängden RAM som är avsedd för din cache är mindre än du hade väntat dig, bör du undersöka närmare i varför det är så. Kanske är det så att du inte låter din SQL Server allokera mängden RAM som ska användas dynamiskt. Vad det än beror på, så måste du finna en lösning eftersom mängden data cache som finns ledigt på din SQL Server kan påverka prestandan markant.
Eftersom antalet användare som använder din SQL Server kan påverka prestandan, så kanske du bör hålla ett öga på ”The SQL Server General Statistics Object: User Connections”. Den påvisar antalet användaranslutningar (inte antalet användare) som är uppkopplad mot SQL Servern för tillfället. När du tolkar dessa siffror bör du tänka på att en användare kan ha flera anslutningar uppkopplade samtidigt på servern, samtidigt som flera användare kan dela på en anslutning. Räkna inte blint med att siffrorna representerar det faktiska antalet användare som är uppe. Använd istället siffrorna so referensmaterial till hur mycket servern ”används”. Om användandet ökar så kan du använda informationen till att göra en plan för vilken hårdvara som kan komma att behövas i framtiden.
En anledning till överdriven användning av I/O på din server är ”page splitting”. Page splitting inträffar då ett index eller en datasida blivit fylld och därmed delas av den aktuella sidan och den nya sidan som skapas. Page splitting som inträffar ibland är normalt, men när det sker överdrivet mycket så kan det skapa problem i prestandan. För att få reda på om det inträffar en stor mängd page splittings, så kan du övervaka ”The SQL Server Access Methods Object: Page Splits/sec”. Tyvärr har jag inga rekommendationer att ge dig för antalet maximala page splittings som får ske. Målet är dock att du bör hålla den siffran så låg som möjligt. Det du kan göra är dock att övervaka läget under en period för att se om antalet page splittings ökar. Om det gör det bör du kanske bygga om Indexen för tabellerna i databasen, och när du gör det så kan du öka fyllfaktorn.
Om dina användare klagar på lång väntetid när de utför transaktioner, bör du ta reda på om det är objektlåsningarna på servern som bidrar till problemet. För att göra det kan du övervaka ”The SQL Server Locks Object: Average Wait Time (ms)”. Du kan använda denna Counter för att ta reda på den genomsnittliga väntetiden för olika låsobjekt, t ex databasen, begränsningar, nycklar, sidor, RID och tabeller. Om du kan identifiera det objekt som skapar väntetider i transaktioner, så kan du forska vidare i om det är vid speciella transaktioner som låsningarna uppstår. Till dessa mer detaljerade analyser kan du använda Profilern.
Trots att genomsökningar av tabeller faktiskt sker ofta, och trots att de kan vara snabbare genomsökningar av Index, så bör man hålla nere antalet tabellsökningar. För att få reda på hur många av dessa som din Server utför så kan du övervaka ”The SQL Server Access Methods Object: Full Scans/sec”. Notera att denna Counter gäller för hela Servern och inte bara för en specifik tabell. En sak som du kommer att märka när du använder denna Counter är att tabellsökningar ofta verkar ske periodiskt enligt något mönster. I många av fallen så är det bara SQL Servern som regelbundet utför tabellsökningar för internt bruk. Det du bör leta efter är dem tabellsökningar som sker oregelbundet, för det är dem som representerar din applikations utföranden. Om du upptäcker att det sker många genomsökningar av dina tabeller så kan du plocka fram Profilern och Index Tuning Wizarden. De kan hjälpa dig bestämma vad det är som orsakar sökningarna – samt hjälpa dig se om det skulle gå att reducera antalet sökningar genom att skapa några Index. Självklart kan det ju vara så att SQL klarar jobbet fint och att det effektivaste sättet kanske är att söka igenom tabellerna i stället för Indexen.
Om du misstänker att dina backup- eller återskapningsoperationer, körs i en undermålig hastighet, så kan du verifiera dina misstankar genom att använda ”SQL Server Backup Device Object: Device Throughput Bytes/sec”. Denna Counter kan ge dig information om du snabbt dina backup operationer utförs. För att ytterligare bevisa dina misstankar kan du använda ”The Physical Disk Object: Avg. Disk Queue Length counter”. Om du skulle ha problem med backup- eller återskapningsoperationer, så är det högst troligt att det orsakas av en I/O flaskhals.
0 Kommentarer