Microsoft SQL Server & Solid State Accelerators
Förord
Solid State Accelerator gör det möjligt för dig att ge din yttre lagring ett snabbt minne. Huvudsakligen, en Solid State Accelerator är en Solid State minnes teknik med en attityd, vilken simulerar en konventionell hårddisk eller en array. Den innehåller en inbyggd UPS backup system som tillåter data att kopieras till en tillgänglig disk array i händelse av strömförlust, vilket förhindrar dataförlust.
Microsoft SQL Server & Solid State Accelerators
av Jeff GarbusSå varför skulle en DBA vara intresserad av Solid State Accelerator? Det finns många anledningar, till exempel.
- Du har ställt in din databas för bästa prestanda, frågor körs optimalt, men på grund av transaktions eller frågevolymer, överstiger processbehovet hårdvarans kapacitet, och du behöver utforska andra lösningar.
- Du har inte tid före släppet av en ny SQL server databas applikation för att fullt hinna utvärdera alla prestationsproblem, men du vet att du har dem, och söker en snabb och permanent hårdvaru lösning, vilket inte kräver ändringar av servern eller koden.
- Du vet att du har en I/O flaskhals, kanske även vet var, och vill veta speciellt hur (eller om) Solid State minnes teknik kan hjälpa dig.
I den här artikeln kommer vi att diskutera när Solid State minnesteknik är den korrekta lösningen på din Microsoft SQL servers prestanda problem, och speciellt hur man implementerar det.
När är hårdvara svaret?
Generellt, folk inom mjukvaru industrin gillar att titta efter mjukvara som lösningar.
Många erfarna DBAs, författaren inkluderad, har en känsla av misslyckande om inte applikationen körs smärtfritt med de restriktioner som finns med befintlig hårdvaru konfiguration.
Den här känslan är “dum”, självklart. Du kan finjustera din applikation inom gränserna, men du kan inte komma över hårdvaru begränsningar med mjukvaru inställningar. Ibland pekar mjukvaran på hårdvarans begränsningar med mjukvaru inställningar (exempel finns nedanför) men många gånger behöver en erfaren DBA bara veta när denne ska sluta mixtra med mjukvaran och istället titta på hårdvarans begränsningar
Processen med finjustering är en process för att identifiera och eliminera flaskhalsar.
Det kommer alltid att finnas flaskhalsar som begränsar din applikations bandbredd.
Finjusteringen är en process som framgångsrikt flyttar flaskhalsar till ställen som har tillräckligt hög bandbredd för att hantera din datas genomströmnings behov. Ibland behöver du en lösning på ett databas prestations problem som inte kan lösas genom mjukvara.
Den traditionella reaktionen på ett uppfattat hårdvaru problem är att köpa mera hårdvara- mest vanligt är minne eller/och Processor. Jag har varit i ett antal olika affärer som har köpt mera processorer (4-8 processorer), eller mer minne (4-8GB), och som inte sett en markant ökning av prestandan. Ofta, lägga till en processor är en vansinnig reaktion på en uppfattning om dålig användar genomströmning. Mer ofta än aldrig, lägga till mer minne är en begriplig patentlösning på I/O problem, med den tanken att mera minne tillåter mer chachning, vilket ökar prestandan. Det finns många anledningar till detta, men de leder alla denna slutsats. Om du köper mera minne eller processor för att lösa et I/O problem, så kanske du kastar bort dina pengar. (Se Mike Plutas vita sidor” The Tragedy of throwing Memory at an I/O Problem”)
För att summera den här artikeln, lägga till mera minne kanske lindrar symptomen på ytan, men maskar mer än det löser det underliggande problemet.
För att göra det värre, närhelst din server eller operativsystem bestämmer att det behöver mer minne för andra saker, så skiftar din flaskhals, plötsligt och oförutsett. Den kan skifta fram och tillbaka många gånger, vilket gör det svårt att hitta vad som orsakar flaskhalsen.
Tricket är att lösa den specifika flaskhalsen, så att individuella problem löses och är skalbara, så att din om process behöver ökas, du kan använda samma (eller en jämförbar lösning) för att lösa framtida flaskhalsar. Så att säga, när du har identifierat ett problem, så vill du lösa det problemet, inte gömma det.
Som summering, det finns två grundorsaker för att välja en hårdvaru lösning på ett prestandaproblem. Först, du har identifierat en speciell hårdvaru flaskhals, i vilket fall borde du välja en hårdvaru resurs som adresserar det problemet (processor, minne eller Solid State minne). För det andra, du har identifierat ett applikations problem, och har beslutat att du har kort om tid eller resurser för att lösa det (alternativt, hårdvaran löser problemet billigare på kortare tid.)
Identifiera hårdvaru flaskhalsar
Det lättaste sättet att förstå ditt hårdvaru problem är att använda de verktyg som Microsoft har, speciellt Performance Monitor. Används Performance Monitor, så kan vi identifiera ett småproblem i varje del av prestanda objektet. Det specificerade innehållet i prestanda objektet kommer att variera beroende på vilken version av NT/Windows som du använder.Oavsett version på ditt operativsystem, så vill du övervaka dina fysiska diskar. Observera att övervaka diskarna kommer att skapa lite system overhead. Historiskt, har detta varit en ökning med 3-5 % av processorn, men i senare versioner av NT/Windows 200, verkar det ha haft en mindre påverkan. Om du inte redan har slagit på det, så måste du sätta på diskräknaren vid kommandoprompten, skriv ”diskperf –y", tryck ENTER, starta sedan om.
Varje disk i ditt system kommer att ha ett separat disk objekt. Det ger dig möjlighet att förstå, för varje objekt, med vilken frekvens den används. För varje fysiskt disk objekt, kan du se % disk tid, vilket kommer att tala om hur upptagna diskarna är. Notera att du kanske upplever hårdvaru begränsningar innan du får 100% upptaget.
Om du ser en linje på toppen av Performance monitorn, snarare än på botten, då kan du ha en I/O del som inte hänger med i vad systemet kräver. Generellt, om du har över 70 -75 % utnyttjande regelbundet, då har du inte tillräckligt med kapacitet för att hantera data pikar.
Dessutom, kontrollera din Avg. Disk Queue Length. Den borde alltid vara mindre än 10 och oftast så är den noll. När den genomsnittliga kölängden ökar, ökar diskens väntetid. Väntetiden betyder att systemet väntar medan en annan I/O har åtkomst till disken.
Tillfälliga väntetider är normalt, men om det är stadigt återkommande så har du en I/O flaskhals. [Författarens not. SQL-Server Performance.com rekommenderar att den genomsnittliga disk kölängden ska vara mindre än 2 för bästa disk prestanda.
Du kan titta på andra indikatorer, men dessa borde vara tillräckliga för att identifiera problemen.
Lösa det specifika problemet
När du har fastställt att du har en I/O flaskhals som behöver lösas, så måste du bestämma bästa sättet att lösa det på. Det vore enkelt att ersätta hela disk systemet med en Solid State Accelerator, men det är kanske inte nödvändigt. Utmärkande, en liten del av disken kan behöva placeras på ett Solid State minne för att erhålla en betydligt större prestanda fördel.
Nyckeln är att identifiera rätt subsystem och filer som ska placeras på Solid State Accelerator som ger ditt stressade system den I/O lättnad som det behöver.
På samma gång är det viktigt att bestämma den mängd av Solid State minne som du behöver för att få önskat resultat. Det vill säga Solid State minne översätter direkt mot att ersätta standard roterande diskar. Du vill så klart välja de mest aktiva filerna att placera på Solid State Accelerator, för att få bort det från de ansträngda diskarna där I/O flaskhalsarna är som värst. Bra exempel filer att lägga på en Solid State inkluderar:
- Tempdb , en väldigt frekvent flaskhals för komplexa online applikationer så väl som beslutsunderstöds applikationer som använder sammanslagnings funktioner ( och därför, tempdb). Tips: Du kanske har 5GB med tempdb, men undantagen den mest upptagna tiden används bara 1-2GB i det här fallet, så kan du konfigurera den första enhetens fragment att finnas på Solid State, och överflödet på andra enheter. Vi rekommenderar att du inte använder ”autogrow” funktionen, här, eftersom den kommer att ha en negativ påverkan på prestandan just när systemet är som mest upptaget.
- Transaktions loggen på väldigt upptagna ( skriv intensiva) databaser ( samma tips här, du behöver inte göra det för hela transaktions loggen, men att lägga den först kan vara effektivt.).
- Databaser som har många träffar, vilket kan vara katalog information, uppslags tabeller eller annan information som har träffar konstant, men som kanske är för små för att det ska vara värt att sprida ut dem, är också bra kandidater. Notera att när SQL Serverns data cach kanske jobbar bra, är allt som kanske behövs är en stor tabell skanning för att rensa användbara sparade sidor från minnet.
Hög tillgängliga Solid State Accelerators har ett inbyggt UPS system som gör dem osårbara.
För den osannolika händelsen av strömpikar, försörjer det inbyggda UPS systemet datorn och de inbyggda hårddiskarna används för att effektivt backa upp innehåller i Solid State minnet. När strömmen är stabil igen, laddas användar data tillbaka till Solid State minnet.
Häftiga options för att maximera dina hårdvaru pengar
Vad händer när du behöver ändra på en förutsägbar basis?. Som exempel, du kanske har en hög volym OLTP process som körs från 8-5, och en stor batch process på kvällen. Dina flaskhalsar skiftar två gånger om dagen.
Konceptet på en Storage Virtualization i en Storage Area Network (SAN) get dig möjligheten att lösa övergångs flaskhalsar nästan på en på efterfrågan basis.
Som exempel, låt oss anta att du har 5GB av Solid State minne som en del av din SAN. Under dagen, så kanske du placerar tempdb på Solid State minnet för att eliminera din I/O flaskhals.
På natten, så kanske du åter allokerar Solid State minnet till att adressera din batch process behov, vilket har kommit till den punkten att den sträcker batch uppdateringen över dess begränsningar.
Sköta ett SAN, du speglar tempdb från Solid State Accelerator till en disk för den processen, och sen speglar databasen till den för batch processning. När det ä färdigt, så speglas allt tillbaka och det är klart för nästa affärsdag.
Du kommer att notera att allt detta görs på ett sådant sätt för att vara helt transparent för servern och slutanvändarna. Plötsligt, Solid State minne blir en återanvändbar resurs, med en Accelerator som kan stödja fler miljöer och att kapaciteten kan allokeras när den behövs för att öka prestandan i fler applikations miljöer. Fortsatta fördelar kan uppnås genom att använda en större Solid State Accelerator och dedicera en del av den att fixa data och ha andra utrymmen tillgängliga för hotspot användning.
Låt oss titta på en klient till mig som hade problem att nå 100GB/vecka genomströmning med SQL 6.5 Server. Deras batch körningar hade en väldigt stor användning av tempdb. På grund av att en osorterat högvolyms processning behövs, SAN lösningen skulle inte fungera för dem.
Den här klienten kämpade i veckor för att trimma systemet, när lösningen inte kunde ha varit enklare. Baserat på deras uppmätta genomströmning, en liten 2GB Solid State Accelerator för tempdb, och en 10GB MegaCach i fronten på deras 400GB produktions databas kunde ha löst 100% av deras genomströmnings problem direkt.
Slutsats
Har du någon gång haft problem med I/O, försökt att sprida den över flera enheter, försökt att skriva om procedurer, Omdesignat databasen, och fortfarande inte löst det? Eller kanske, just har löst det och vet att problemet kommer att komma igen. Kanske är det tempdb (en frekvent syndare). Kanske finns det i din miljö, dina kod tabeller helt enkelt har så många träffar att din upptagna webb applikation inte hinner med.
Jag har sett ett flertal (och hört om dussinet med) situationer där I/O begränsningar verkligen var ett problem, men folk skulle aldrig erkänna det innan applikationen var finjusterad och justerad igen. Vid den punkten, så skickar de in ett Solid State minne och undrar varför de inte gjorde det tidigare.
Solid State minne är en snabb, ren, enkel lösning på problem som ibland behöver tids förbrukning, dyrbar underhållande resurs jonglerande. Ibland, kanske snabbaste, enklaste. lösningen är billigare i långa loppet, när du väger in utvecklingstid och löpande underhålls kostnader
Det är en väldigt specifik del av problem som Solid State minne mottar, men den löser dem helt. Gör klart för dig att du förstår det prestanda problem som du försöker att lösa. När du förstår detta, så kanske du upptäcker att Solid State minne går från ”intressant ide” till en ” väsentlig, kostnadseffektivt verktyg för att lösa specifika prestanda problem” väldigt snabbt.
0 Kommentarer