Utför en prestandaanalys av din SQL Server #3
Förord
Innehåll
»»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
Checklista för hårdvaruprestanda
av Brad M. McGee
Checklista för prestandaanalys
Skriv in dina resultat i tabellen ovan
SQL Server hårdvaruanalys är ett viktigt, tidigt steg
I förra artikeln då vi använde Performance Monitor så kanske du identifierade potentiella flaskhalsar i hårdvaran. Det är inte alls bra för SQL Serverns prestanda. I den här artikeln ska vi ta en titt på var och en av de stora komponenterna i en SQL Servers hårdvara, och se vad som kan göras för att maximera hårdvarans prestanda. Den här delen av analysen kommer att delas upp i följande avsnitt:
- CPU
- Minnen
- Disklagring
- Nätverksanslutning
- Diverse blandat
Som en del i analysen så måste du fylla i checklistan ovan. Och medan du gör det så kan du få reda på saker om din Server som du inte hade en aning om.
CPU
Antalet CPUn
Den första punkten är uppenbar; ju mer CPU du har i Servern, desto snabbare kan Servern arbeta. Standardversionen av SQL Server kan stöda upp till 4 CPUn. Om du vill ha stöd för fler än 4 CPUn, upp till 32 CPUn då du använder Windows 2000 Datacenter Server, så måste du köra SQL Server 2000 Enterprise Edition. SQL Server använder sig av flera CPUn för att effektivt kunna höja prestandan.
Det är svårt att avgöra hur många CPUn en specifik SQL Server baserad applikation kan behöva. Det beror på att varje applikation både arbetar och används olika. Erfarna DBAn har ofta en känsla inbyggd för hur mycket CPU kraft en applikation kan behöva, men fram tills att du har testat just din Servers konfigurering under realistiska former, så kan det vara svårt att veta hur mycket som egentligen krävs.
Eftersom det är så pass svårt att välja ett lämpligt antal CPUn till din SQL Server, så har jag ett par tumregler att gå efter:
- Införskaffa en Server med så många CPUn som du har råd med
- Om du inte kan göra det, så bör du åtminstone införskaffa en Server med plats för expandering av antalet CPUn. Med tiden behöver nästan alla Servrar mer kraft då arbetslasten ökar.
Här följer några potentiella scenarion:
- SQL Servern ska användas till en specialiserad uträkningsapplikation som bara kommer att användas av 5 användare samtidigt, och du räknar med att det kommer att vara så i ett par år. Om så är fallet så räcker det gott och väl med en CPU. Men om du räknar med att antalet samtida användare kommer att öka inom den närmaste tiden, så kan du införskaffa en Server med en enda CPU, och med plats för ytterligare en CPU ifall behovet skulle uppstå.
- SQL Servern ska användas till en speciell applikation som är skriven av företaget. Applikationen kommer inte bara att innefatta OLTP, utan behöver också support för relativt höga rapporteringsbehov. Man räknar med att antalet samtida användare inte kommer att överskrida 25. I det här fallet så bör du införskaffa en Server med 2 CPU, men med möjligheten att utökas till 4 om det skulle behövas. Det är svårt att förutse vad som menas med en ”relativt högt rapporteringsbehov”, men jag har sett exempel på relativt simpla, och dåligt skrivna rapporter, som har slagit ut en Servers CPU.
- SQL Server ska köra ett ERP paket som kan stöda mellan 100-150 samtida användare. För tunga applikationer som den här, så bör du fråga försäljaren om rekommendationer för hårdvaran, eftersom de bör ha en bra uppfattning för hur mycket CPU deras produkt behöver.
Jag skulle kunna ge flera andra exempel, men det jag försöker visa på är hur svårt det är att förutse hur många CPU en SQL Server baserad applikation kan komma att behöva. Och du bör se till att införskaffa ett större system än vad du tror att du behöver, för i de flesta fall så underskattar man gärna användarkraven för en applikation. Det kan bli billigare i längden genom att införskaffa en större Server just nu (med flera CPUn), än att behöva byta ut Servern 6 månader senare, bara för att den gamla inte klarade förväntningarna.
Hastighet på CPU
Precis som det är med antalet CPU, så kan det vara svårt att förutse hur snabba CPUn som du måste införskaffa. Generellt sett så gäller det samma sak som med antalet CPUn, skaffa de snabbaste CPUn som du har råd med. Det är bättre att införskaffa ett för stort system än ett för litet system.
CPU L2 Cache
En av de vanligaste frågorna jag får är; Bör du införskaffa billiga CPUn med mindre L2 Cache eller de dyrare XEON CPUn med större L2 Cache? Det som gör det här valet så komplicerat är det faktum att du kan införskaffa snabbare chips med en mindre L2 Cache än med en större L2 Cache. Här är min tumregel:
- Om du bara ska köra med 1 eller 2 CPUn, så bör du köpa det snabbaste du kan få tag på, och tänka på L2 Cache i andra hand. Om du skulle ha flera val sen när det gäller storleken på L2 Cache, köp då det största alternativet.
- Om du däremot ska köra med 4 eller fler CPUn, så bör du skaffa den CPUn som har störst L2 Cache, trots att inte hastigheten är den snabbaste. Anledningen för det är att en SQL Server som har 4 eller fler CPUn behöver mycket större L2 Cache för att fungera optimalt, annars kommer du bara att slösa på effekten från de extra CPUn.
Checklista för CPU analys
Eftersom den här artikeln handlar om hur du analyserar din SQL Servers aktuella CPU kapacitet, så ligger nu fokusen på huruvida din aktuella Server har råkat ut för flaskhalsar i CPUn eller inte. Precis som vi diskuterade i förra artikeln, så kan du använda Performance Monitor till att identifiera flaskhalsar i hårdvaran.
Om du för tillfället inte har några flaskhalsar i CPUn, så kan du hoppa över till nästa avsnitt om Minnen. Men om du har flaskhalsar i CPUn (vilket kan skapa enorma prestandaproblem i din SQL Server), så kan du ta till följande åtgärder för att lösa dem:
- Reducera lasten på din Server. Det kan du göra genom att; reducera mängden användare på den, optimera dina SQL-satser, optimera dina Index samt ta bort onödiga applikationer som körs på Servern. Ytterligare ett alternativ är att flytta på rapporteringsbehovet från din produktionsserver till en SQL Server som enbart är till för rapporteringar.
- Förutsatt att din flaskhals i CPUn beror på för lite minne i Servern (vilket är ett vanligt problem) så kan du lägga till extra minne.
- Lägg till extra CPUn i Servern, i mån av plats
- Uppgradera till snabbare CPUn i servern, om det är genomförbart
- Införskaffa en ny Server, med fler och snabbare CPUn
Tyvärr så är ingen av lösningarna för flaskhalsar i CPUn särskilt enkla att implementera, om inte ditt företag har obegränsat med pengar att spendera. En DBA som har hand om en SQL Server med flaskhalsar i CPUn, har många svåra val att göra, och massvis med arbete framöver sig. Speciellt om du bara kan ta till alternativet ”Reducera lasten på SQL Servern”, på grund av för lite pengar.
Minnen
Bara för att vi diskuterar Serverns minnen nu efter att vi har diskuterat Serverns CPU, tro inte då att minnena inte är lika viktiga som CPUn. Faktum är att minnet förmodligen är den viktigaste komponenten i en Servers hårdvara, och det påverkar Serverns prestanda mer än någon annan hårdvara. När vi talar om Minnen så talar vi om det fysiska RAM minnet. Ofta refereras ordet Minnen (i Windows NT och 2000) till fysisk RAM och virtuellt minne (Swap fil). Men den förklaringen duger inte för en SQL Server, eftersom SQL Server inte är designad till att använda sig av virtuellt minne (fast den kan det om den verkligen måste).
Istället för att använda operativsystemets kombination av fysiskt RAM och virtuellt minne, så föredrar SQL Servern att använda sig utav det fysiska RAM minnet så mycket den kan. Anledningen till det beror på hastigheten. Det går mycket snabbare att hämta ut data från RAM minnet än att hämta ut det från hårddisken.
När SQL Servern inte längre kan lagra all data som den hanterar i RAM minnet (SQL Serverns Buffer Cache), så accessar den hårddisken på samma sätt som operativsystemet gör med det virtuella minnet. Men SQL Serverns “Cachingmekanism” är mer sofistikerad och mycket snabbare, än vad det virtuella minnet i operativsystemets kan prestera.
Det snabbaste sättet att få reda på om din SQL Server har tillräckligt med RAM är genom att kolla SQL Server: Buffer Cache Hit Ratio Countern, som vi diskuterade i förra artikeln. Om Countervärdet ligger på 99 % eller högre, så har du högst troligt tillräckligt med fysisk RAM i din SQL Server. Om Countervärdet ligger mellan 90-99 %, och om du känner dig nöjd med SQL Serverns prestanda, så har du förmodligen tillräckligt med fysiskt RAM minne i din SQL Server. Men då du inte är nöjd med din Servers prestanda, så bör du lägga till extra minne.
Om Countervärdet dock ligger under 90 %, så är oddsen höga för att din Servers prestanda är oacceptabel (om du inte kör en OLAP applikation, då är generellt sett värden under 90 % OK), och du bör då definitivt lägga till extra RAM minne.
Det idealiska vore om mängden fysisk RAM i din Server överstiger storleken på den största databasen i Servern. Det är dock inte alltid möjligt, då en del databaser kan vara enormt stora. Om du håller på och gör i ordning en ny Server så bör du, förutsatt att din budget är tillräckligt stor, försöka förse din SQL Server med tillräckligt mycket fysisk RAM för att kunna täcka storleken för alla lagrade databaser. Om din databas är 4 GB eller mindre, så är det oftast inga problem. Men om dina databaser är större än, eller förväntas växa över 4 GB, så kan det vara svårt att ha råd med RAM minne som är större än 4 GB. Trots att SQL Server 2000 Enterprise Edition kan stödja upp till 64 GB RAM, så finns det få prisvärda Servrar som kan stöda så mycket RAM.
Även om du inte skulle lyckas få in hela databasen i SQL Serverns Buffer Cache, så kan SQL Server ändå vara relativt snabb när det handlar om att få ut data. En 99 % Buffer Cache Hit Ratio innebär att de data som SQL Server behöver, redan finns i cachen 99 % av gångerna, vilket ger hög prestanda. Låt oss t ex säga att jag hanterar en databas som är 30 GB stor, men min Server har bara 4 GB RAM. Min Buffer Cache Hit Ratio för den Severn ligger alltid på 99,6 % eller högre. Det innebär för det mesta att användarna bara accessar en liten del av databasen samtidigt, och att SQL Servern har förmågan att lagra de data som används mycket i Buffer Cachen. Så mer än 99 % av gångerna som användarna försöker komma åt data så finns de data i Buffer Cachen, trots att mängden RAM minne i Servern inte täcker hela databasens storlek.
Så vad innebär allt det här? Om din Buffer Cache Hit Ratio ligger under 99 %, så bör du allvarligt överväga att lägga till extra RAM minne.
Disklagring
Näst efter minnet så är disklagringen den viktigaste faktorn för SQL Serverns prestanda. Det här är också ett komplicerat ämne, så jag har i det här avsnittet valt att ta upp de lättaste områdena, där du kan höja din disklagringsprestanda.Totala mängden ledigt utrymme på Servern
Trots att det inte påverkar prestandan särskilt mycket, så är det viktigt att alla dina arrayer har åtminstone 20 % ledigt utrymme. Det beror på att NTFS (vilket är det diskformatet jag antar att du använder dig av) behöver extra plats för att kunna arbeta effektivt. Om det utrymmet inte är tillgängligt så kan inte NTFS utnyttja hela sin kapacitet, och prestandan tar skada. Det leder också till mer diskfragmentering, vilket gör att hårddisken måste arbeta hårdare för att läsa och skriva data.
Ta en titt på var och en av dina fysiska diskar i SQL Server och se om det finns åtminstone 20 % ledigt utrymme. Om det inte finns det, överväg då följande:
- Ta bort onödig data från hårddisken
- Flytta en del data till hårddiskar som har större plats
- Lägg till mer diskutrymme
Totala antalet fysiska diskar i varje array
En diskarray är generellt sett två eller fler fysiska hårddiskar som arbetar tillsammans som en enda enhet. En exemplevis RAID 5 array kan ha 4 hårddiskar. Så varför är det så viktigt att veta hur många fysiska diskar det finns i en eller flera arrayer i din SQL Server?
Med undantaget av speglade arrayer (viket är två fysiska diskar som jobbar ihop), så gäller det att ju fler fysiska diskar det finns i en array, desto snabbare kan man läsa och skriva från arrayen.
Låt oss t ex säga att jag vill införskaffa en ny SQL Server med en RAID 5 array, och att jag då behöver åtminstone 100 MB ledigt utrymme. Låt oss också leka med tanken att min försäljare har föreslagit två olika RAID konfigurationer:
- 4 – 36 GB diskar (108 MB ledigt)
- 7 – 18 GB diskar (108 MB ledigt)
Båda alternativen möter våra kriterier att förse mig med 100 MB ledigt utrymme i en RAID 5 array. Men vilken array ger bäst skriv- och läsprestanda? Det gör det andra alternativet med 7 18 GB diskar. Varför?
Generellt sett så handlar det om att ju fler diskar du har, desto fler disk heads finns det tillgängliga för att kunna skriva och läsa data. Exempelvis SCSI diskar har förmågan att kunna läsa och skriva simultant. Så ju fler fysiska diskar som finns i en array, desto snabbare går det att läsa och skriva data från arrayen. Hårddiskarna i en array delar upp arbetslasten mellan sig, och ju fler ju bättre. Det finns vissa begränsningar beroende på disk controllern, men generellt sett gäller ju fler ju bättre.
Så vad innebär det här för dig? Efter att du har tittat på hur många arrayer du har i din Server, och sen på hur många fysiska diskar det finns i varje array, är det då möjligt att du kan konfigurera om din aktuella array till att dra fördel av uttrycket ”mer är bättre”?
Låt oss t ex säga att du har två diskarrayer som båda används till att lagra stora databaser. Var och en av arrayerna är en RAID 5 array, med 3 stycken 18 GB hårddiskar i varje. I det fallet så kan det vara bättre att konfigurera om arrayerna till en stor array med 6 stycken 18 GB diskar. Det skulle inte bara ge dig snabbare I/O, utan det skulle också återge 18 GB hårddiskutrymme.
Se noga över din aktuella konfiguration. Det skulle eventuell kunna gå att göra en del där. Om det går att göra nåt åt den nuvarande konfigurationen så märker du skillnaden med en gång.
Olika RAID nivåer som du kan använda till SQL Server databaserna
Som du förmodligen redan vet så finns det olika sorters diskarraykonfigurationer, så kallade RAID nivåer. Var och en av RAID nivåerna har sina för- och nackdelar. Här kommer en kort sammanfattning av de vanligaste RAID nivåerna, samt hur de bäst används i SQL Server.
RAID 1
- Det idealiska vore om operativsystemets och SQL Serverns körbara filer, inklusive operativssytemets Swapfiler, låg på en RAID 1 array. Vissa människor lägger Swapfilerna på en egen RAID 1 array, men jag tvivlar på att det erbjuder särskilt mycket högre prestanda, eftersom paging inte är något problem på en välkonfigurerad Server.
- Om din(a) SQL Server databas(er) är väldigt små och om alla databaser kan få plats på en enda hårddisk, så bör du överväga att använda RAID 1 lösningen för att lagra dina datafiler från SQL Server.
- Det idealiska vore om varje separat transaktionslogg låg på en varsin RAID 1 array. Det beror på att transaktionsloggarna läses och skrives successivt, och genom att isolera dem på en varsin array, så blandas inte den successiva disk I/O ihop med den långsammare blandade disk I/O, och därmed höjs prestandan.
RAID 5
- Trots att det här är den pouläraste bland alla RAID lösningar, så är det inte alltid det bästa alternativet för optimal SQL Serverns I/O prestanda. Om en databas upplever mer än 10 % skrivning, vilket de flesta OLTP applikationerna gör, så kommer prestandan att ta skada, vilket i sin tur skadar all I/O prestandan för SQL Servern. RAID 5 används bäst till read-only databaser, eller sådana som oftast är read-only. Tester från Microsoft visar på att RAID 5 lösningen kan vara upp till 50 % långsammare än RAID 10 lösningen.
RAID 10
- RAID 10 ger den bästa prestandan för SQL Server databaser, och den är den dyraste av alla RAID lösningar. Ju mer skrivaktiviteter det är i databasen, desto viktigare är det att använda RAID 10 lösningen.
- RAID 10 arrayer är också ett bra alternativ för transaktionsloggar, förutsatt att de är helt hängivna till en enda transaktionslogg.
Det troligaste är att dina aktuella SQL Server konfigurationer inte matchar ovanstående rekommendationer. I vissa fall så kan det gå att modifiera dina aktuella arraykonfigurationer till att matcha något av alternativen ovan, men i andra fall så måste du förmodligen leva med det du har, tills din budget säger att du kan köpa en ny Server och en ny array.
Om du bara kan välja en av rekommendationerna ovan, så skulle jag rekommendera att du väljer RAID 10 lösningen över de andra alternativen. Det alternativet skulle ge dig den högsta I/O prestandan i SQL Server.
Hårdvaru- mot mjukvaruRAID
RAID kan implementeras genom hårdvara eller mjukvara (via operativsystemet). Och det är ingenting att diskutera; Använd aldrig mjukvaruRAID, den är väldigt långsam. Använd alltid hårdvaruRAID.
Nivån på diskfragmentering
Om du skapar en databas på en splitter ny diskarray, så kommer databasfilen och transaktionsloggfilen att skapas som en enda kontinuerlig fil. Men när din databas och transaktionslogg växer (och vilken databas och transaktionslogg gör inte det), så kommer filerna någon gång att bli fragmenterade. Filfragmenteringen, vilken sprider ut delar av filen över hela diskarrayen, leder till att diskarrayen får det jobbigt att hitta, skriva och läsa filen, vilket skadar I/O prestandan. Som en del av din prestandaanalys, så måste du ta reda på hur defragmenterade din SQL Server databas och transaktionsloggar är. Om du har SQL Server 2000 så kan du använda dig av det inbyggda defragmenteringsverktyget och göra en fragmenteringsanalys för att se hur fragmenterade filerna egentligen är. Om du kör Windows NT 4.0 så får du utföra analysen med hjälp av ett tredjepartens verktyg, som t ex Diskeeper från Executive Software.
Om analysen rekommenderar dig att defragmentera så bör du göra det. Tyvärr så är det ingen lätt uppgift att defragmentera din SQL Server databas och dina transaktionsloggar. Det går inte att defragmentera filer som är öppna och används, som t ex SQL Server databasen och transaktionsloggarna. För att kunna defragmentera filer så får de inte vara öppna. Det innebär att om du vill defragmentera SQL Server databasen och transaktionsloggarna så måste du stänga ner SQL Server under defragmenteringsprocessen. Och beroende på storleken på filerna, och på hur fragmenterade de är, så kan det ta flera timmar.
Men har du något annat val då du vill defragmentera dina SQL Server filer? Om din I/O prestanda verkar vara tillräcklig, så behöver du inte bry dig om att defragmentera. Men om du har en flaskhals i I/O så är defragmentering det billigaste sättet att höja din prestanda på, trots att det i många fall är tidskrävande.
Det idealiska vore om du defragmenterade dina SQL Server filer regelbundet. På så sätt kan du försäkra dig om att du inte får några flaskhalsar i I/O prestandan, bara för det här vanliga problemet.
Lokalisering av operativsystemet
För högsta prestanda så bör inte operativsystemet ligga på samma diskarray som SQL Serverns datafiler (MDB och LDF). Det bör istället ligga på en diskarray som stöder RAID 1, 5 eller 10.Jag brukar vanligtvis, som de flesta gör, installera operativsystemet på C: disken på Servern. Jag brukar oftast konfigurera C: disken som en RAID 5 (speglad) hårddisk för både feltolerans och den högsta prestanda.
För det mesta kan du lägga dina filer för operativsystemet vart du vill på Servern, så länge som de inte ligger på samma array som SQL Serverns datafiler. Dess exakta lokalisering har ingen betydelse för prestandan.
Lokalisering av SQL Serverns körbara filer
Vart du placerar SQL Serverns körbara filer är, likt operativsystemets lokalisering, inte så noggrant, så länge som de inte ligger på samma array som SQL Serverns datafiler. Och precis som med operativsystemets filer så brukar jag vanligtvis lägga SQL Serverns körbara filer på C: disken, som är konfigurerad som en RAID 5 (speglad) hårddisk.Om du däremot håller på att bygga ett SQL Server 7.0 Cluster, så får inte de körbara filerna ligga på C: disken, utan då måste du placera dem på en gemensam array. Tyvärr så blir det ofta samma array som SQL Serverns datafiler ligger på, så till vida att du inte massvis med pengar att spendera på en separat array enbart för de körbara filerna. Trots att det inte är särskilt bra för prestandan att placera de körbara filerna på samma array som SQL Serverns datafiler, så kanske det inte är en alltför dålig kompromiss ändå med tanke på att du får feltoleransen i utbyte. Å andra sidan så kan det vara en bra anledning till att uppgradera till SQL Server 2000 Clustering. Om du bygger ett SQL Server 2000 Cluster så ska de körbara filerna ligga på en lokal hårddisk istället för den gemensamma arrayen, och då spelar inte prestandan någon roll.
Lokalisering av Swapfilerna
Förutsatt att din Server är hängiven till SQL Server och att SQL Serverns minne är satt som dynamisk (standard), så kommer inte Swapfilerna att märka av någon särskild aktivitet. Det beror på att SQL Servern normalt inte använder Swapfilerna. På grund av det så spelar det ingen roll vart du lägger Swapfilerna på Servern, så länge som de inte ligger på samma array som SQL Serverns datafiler. Vanligtvis lägger jag Swapfilerna på samma hårddisk som operativsystemet och SQL Serverns körbara filer. Och precis som jag har nämnt tidigare så är det på en disk som stöder RAID 1, 5 eller 10, vanligtvis C: disken. Det gör administrationen mycket enklare.
Om din SQL Server är en delad Server som kör fler applikationer är SQL Server, så är paging ett problem (på grund av de andra applikationerna). Där bör du överväga att flytta Swapfilerna till en egen array endast för Swapfiler, för att få bättre prestanda. Eller ännu hellre; låt SQL Server vara den enda applikationen som körs på din Server.
Lokalisering av tempdb databasen
Om din tempdb databas används väldigt mycket så bör du överväga att flytta den till en egen array, antingen en RAID 1 eller en RAID 10, för att höja disk I/O prestandan. Undvik RAID 5 arrayer, då de är väldigt långsamma vid skrivningar (vilket sker en hel del i tempdb). Om du inte kan placera tempdb på en egen array, så bör du lägga dem på samma hårddisk som ditt operativsystem – undvik arrayen där databasfilerna ligger. På så sätt undviker du I/O konflikter och höjer I/O prestandan. Om din applikation använder tempdb databasen väldigt mycket och gör så att databasfilen växer sig större än sin standardstorlek, så bör du göra en permanent ökning av tempdb filens standardstorlek. Det beror på att varje gång som SQL Sever tjänsten (mssqlserver) startas om, så återskapas tempdb filen till sin standardstorlek. Trots att tempdb filen kan växa, så krävs det vissa resurser för att kunna göra det. Så genom att din tempdb fil har rätt storlek när SQL Server startas om, så behöver du inte oroa dig för någon extra arbetslast om den skulle växa senare under produktion.
Den höga aktiviteten i tempdb databasen kan dessutom dra ner SQL Serverns prestanda. Speciellt om du skapar en eller flera stora temp tabeller, som du kör SQL-satser mot skapar eller relationer av. För att höja hastigheten på SQL-satserna så måste du se till att databasalternativet AUTOSTATS är påslaget för tempdb, samt skapa en eller flera Index på dessa temp tabeller som kan användas av SQL-satserna. För det mesta så kan du då märka att det höjer hastigheten för applikationen. Men du bör testa det här först för att se så att det verkligen fungerar i just din situation.
Lokalisering av systemets databaser
Eftersom systemets databaser (master, msdb, model) inte upplever särskilt mycket läs- och skrivaktiviteter, så kan du placera dessa databaser på samma array som SQL Serverns datafiler, utan att det spelar någon roll för prestandan. Det enda undantaget är för enorma databaser med hundratals eller tusentals användare. I fall som detta så kan det gå att höja prestandan om du lägger systemets databaser på en egen array.
Lokalisering för användarnas databaser
För bästa prestanda så ska användarnas databaser (MDB) placeras separerat från andra datafiler, inklusive loggfiler, på en egen array (RAID 1, 5, 10). Om du har flera stora databaser på samma SQL Server, så bör du överväga att placera var och en av datafilerna på egna arrayer, för att undvika problem med I/O.
Lokalisering av loggfiler
Det idealiska här vore att placera varje loggfil på en egen array (RAID 1 eller 10, RAID 5 kommer att sakta ner skrivningen till transaktionsloggen mer än du gillar). Det beror på att skrivningar till transaktionsloggen oftast sker synkront, och om arrayen kan skriva data synkront (att den inte behöver avbryta sig själv för att utföra andra skrivningar och läsningar), så kommer sådana skrivningar att gå snabbt. Men om inte arrayen kan skriva synkront utan att den måste blanda andra skrivningar och läsningar, så kommer prestandan att ta skada.Att ha separata arrayer för varje loggfil är självklart dyrt, och kanske inte ens värt pengarna. Men du bör åtminstone lägga loggfilerna på en array (RAID 1 eller 10) där inte databasfilerna är placerade. Trots att inte synkron skrivprestanda är lika som att ha varje loggfil på enskilda arrayer, så är det ändå mycket bättre än att tävla om disk I/O med datafilerna.
Antalet disk controllers i Servern
En enskild disk controller har begränsningar för hur mycket data den kan släppa igenom, oavsett om det gäller SCSI eller fiber. På grund av det så bör du matcha antalet disk controllers med den mängd data som du tror att du kommer behöva släppa igenom. Eftersom varje controller måste hanteras olika så kan jag inte rekommendera några specifika lösningar, mer än att du behöver minst två disk controllers. En av dem ska användas för utrustning som inte har med hårddisken att göra, såsom CD-ROM, backuputrustning, osv. Och den andra ska användas för hårddisken. Målet är att inte koppla både långsamma och snabba utrustningar till en och samma controller. Det här är en bra kombination som du kan se ofta; En disk controller hanterar utrustning utanför hårddisken, en andra controller hanterar en lokal RAID 1 hårddisk, och en tredje controller (ibland även fler) hanterar arrayer som innehåller SQL Serverns databasfiler och loggar. Försäkra dig om att du inte kopplar fler hårddiskar till en controller, än vad den kan hantera. Trots att det kan fungera, så tar prestandan skada.
Typ av disk controllers i Servern
Införskaffa alltid den snabbaste disk controllern som du har råd med, förutsatt att du vill ha den bästa SQL Server prestandan. Som du kanske vet så har olika disk controllers olika utmärkande prestanda. Det finns t ex olika sorters SCSI, såsom Wide SCSI, Narrow SCSI, Ultra SCSI, osv. Det samma gäller fiberanslutningar, fast till en mindre grad.På grund av den breda variationen av controllers så kan jag inte rekommendera någon specifik. Vanligtvis så brukar försäljaren av hårdvara erbjuda flera olika modeller att välja mellan. Fråga denne då om fördelarna i prestandan för var och en av alternativen, och välj den som släpper igenom mest data.
Cachestorleken av disk controllers i Servern
När du införskaffar disk controllers så bör du även se över hur mycket disk Cache de erbjuder. Vissa disk controllers låter dig lägga till extra disk Cache. Du bör generellt sett införskaffa så mycket disk Cache som din controller kan hantera. SQL Server är väldigt I/O intensiv, så vad du än kan göra för att höja I/O prestandan, som att t ex lägga in stora disk Cache, kan hjälpa en hel del.
Är Write Back Cache i disk controllern On eller Off?
Disk Cachen i din disk controller erbjuder två olika sätt att snabba på access. En är för läsning och den andra för skrivning. Av dessa så är läsningen den viktigaste, eftersom det är det disk I/O spenderar mest tid på i de flesta SQL Server databaserna. Å andra sidan så snabbar Write Back Cache upp skrivningar, vilket relativt sett inte sker lika ofta. Tyvärr så förutsätter SQL Servern ofta att Write Back Cache inte är på, och på grund av det så bör du stänga av Write Back Caching på de flesta controllers. Om du inte gör det så är det möjligt att de data som SQL Servern skriver blir skadat (efter att SQL Server har skrivit klart så förutsätter den att det blev korrekt). Men av någon anledning (som t ex dåligt med ström), så skriver inte Write Back Cache ut datan till disken. Trots att det finns vissa controllers som har batteribackup om något sådant skulle ske, så fungerar det inte alltid så som man tänkt sig. Personligen så föredrar jag icke-skadad data (det skrivs lite snabbare) över skadad data (det skrivs lite fortare). Med andra ord så bör du stänga av Write Back Caching på din controller, även fast du kan tappa lite skrivprestanda genom att göra det.
Hastighet på hårddiskarna
De hårddiskar som följer med dina arrayer finns i olika hastigheter. Och som du förstår så bör du införskaffa de snabbaste hårddiskarna som du kan få tag på, för att få högsta prestandan. Vanligtvis ligger det på 15 000 RPM eller snabbare. Försök bara att inte blanda olika hårddiskar med olika hastigheter i en och samma array, för om du gör det så tar prestandan bara skada.
Hur många nätverkskort finns det i Servern?
Som tur är så är det sällan som nätverkstrafiken till och från SQL Servern skapar flaskhalsar, och det räcker oftast gott och väl med ett nätverkskort. Men om du tycker att nätverkstrafiken är ett problem (om du har hundratals eller tusentals användare) så är det berättigat att byta till flera nätverkskort, vilket kan höja prestandan. Dessutom så kan två nätverkskort bidra till redundans, vilket reducerar overksamma tider (down times).
Vilken hastighet har nätverkskorten i Servern?
Din Server bör som ett minimum ha ett 100 MB nätverkskort. Ett 10 MB nätverkskort erbjuder helt enkelt inte den bandbredden som du behöver. Om ett eller fler 100 MB kort inte släpper igenom så mycket data som du behöver, så bör du överväga ett 1 GB kort. Faktum är att du bör skippa 100 MB kort helt och bara använda ett 1 GB kort istället. Genom att använda snabbare nätverkskort så snabbar du inte upp nätverkstrafiken, utan du släpper bara igenom mer data, vilket i sin tur låter nätverkskorten arbeta med sin optimala prestanda.
Är nätverkskorten hårdkodade för Speed/Duplex?
Om du har ett dual 10/100 MB nätverkskort som själv ska känna av hastigheten på nätverket, och därefter ställa in sig efter det, tro inte att det alltid gör det korrekt. Det är väldigt vanligt att ett nätverkskort känner av fel och sätter en lägre än optimal hastighet, och fel Duplex-inställningar, vilket kan skada prestandan. Det du behöver göra då är att sätta nätverkskortets hastighet och Duplex-inställningar manuellt, för då vet du att kortet har rätt inställningar.
Är nätverkskorten kopplade till en Switch?
Det här kan vara ganska uppenbart i stora data center, men i mindre organisationer så kan man fortfarande använda en Hubb för att ansluta till Servern. Om så är fallet så bör du allvarligt överväga att byta ut Hubben mot en lämplig Switch, och sedan konfigurera Switchen till att arbeta med högsta möjliga prestanda, såsom 100 MB och Full Duplex. När du byter ut en Hubb mot en Switch, så märker du omedelbart en skillnad i prestandan.
Är hårdvarans drivrutiner de senaste?
Det här är i sanning ett tråkigt ämne, men det är viktigare än du kanske tror. En av de största prestandabuggarna (och inte att förglömma orsaken till de konstigaste och ovanligaste problemen) är buggiga drivrutiner, oavsett om de finns i disk controllers, nätverket, kort, eller någon annanstans. Genom att använda de senaste drivrutinerna, så är oddsen höga för att du får bättre och snabbare presterande hårddiskar, vilket låter SQL Server att prestera sitt allra bästa.Du bör regelbundet söka efter de senaste versionerna av drivrutiner som finns tillgängliga till din hårdvara, och installera dem under en inaktiv tid. Jag har personligen skådat radikala prestandaförändringar genom att byta ut de gamla, buggiga drivrutinerna till drivrutiner som grundligt har blivit debuggade.
Är den fysiska Servern hängiven till SQL Server?
Jag har nämnt det här förut, men jag kan inte säga det nog ofta. SQL Server bör köras på en hängiven fysisk Server, och inte tillsammans med andra applikationer eller mjukvaror. Om du även kör andra applikationer så tvingar du SQL Server att slåss om fysiska resurser, och du gör det därmed svårt att ställa in din Server för optimal SQL Server prestanda. Om och om igen så får jag förfrågningar om dålig SQL Server prestanda, och om och om igen så finner jag att boven i dramat är en annan applikation som körs på samma Server. Du måste lära dig att säga NEJ.
Vad gör jag nu?
Det har varit en lång resa fram tills nu, och vi har en lång resa framför oss. När jag först undersöker en SQL Servers prestanda och utför prestandaanalyser, så skriver jag ner detaljerade anteckningar om de ovan diskuterade ämnena. Sen jämför jag den nuvarande konfigurationen i Servern med den idealiska konfigureringen, innan jag söker upp enkla vägar till att försöka uppnå den idealiska konfigureringen. Ibland är det lätt (uppenbart, ibland behöver man bara korrigera de misstag man har gjort), och andra gånger så finns det inte så mycket du kan göra. Men det vet du inte förrän du har utfört den här prestandaanalyseringen.Vårt mål är att utföra den del av prestandaanalyseringen som vi har diskuterat i den här artikeln, på var och en av dina Servrar, och sedan använda den informationen du får ut till att göra eventuella korrigeringar – om du kan. Om du inte kan, så kan du använda informationen som ammunition till att få tillåtelse att köpa in ny och bättre hårdvara.
När du har klarat av den här delen i analyseringen, så är du nu redo för att analysera operativsystemet för potentiella prestandaförbättringar.
0 Kommentarer