22. marts 2004 - 18:14Der er
34 kommentarer og 2 løsninger
Vigtighed af ram - hvor mange skal jeg have?
Hej,
Jeg står og skal opgradere min server. Serveren kører windows 2K Server, med MS SQL server. Serveren bliver brugt til både SQL Server, samt IIS. SQLen tager vel 90% af CPU ressourcerne, så er klart det mest krævende.
Jeg har samlet set omkring 30 tabeller, hvor den største er på lidt over en million records, og samlet fylder næsten 1.5 gigabyte.
Hvor mange RAM bør jeg have? Hvis jeg køber 2 (måske 4) gigabyte, vil SQL Server så smide hele tabellen i RAMen, og derved formindske acccess tiden, eller vil det være så minimal at det er spild af penge? Hvis MS SQL server ikke vil bruge rammen til det, vil jeg nøjes med 1 gigabyte ram, som jeg har i min server lige nu.
Håber i kan vejlede mig; vil helst ikke smide penge ud på ram hvis det rent faktisk ikke vil hjælpe det mindste på performance. Det skal lige nævnes at den nye server bliver en 3GHZ P4, og at jeg forventer at kunne udnytte denne server næsten fuldt ud (hovedsageligt fra databasen). Jeg forventer samtidig at alle tabeller ligeså stille stiger i størelse.
Håber i har den information i skal bruge, ellers så bare spørg. På forhånd mange tak for hjælpen.
Det ligger uden for mit ekspertise område. Jeg vil godt fabulere lidt. Men du skal nok vente og også få lidt gode råd fra nogle med praktisk erfaring (f.eks. trer).
Jeg er ret sikker på at du vil se markante forbedringer af performance for 1 GB -> 2 GB.
Jeg er noget mere skeptisk overfor hvorvidt du vil kunne mærke 2 GB -> 4 GB.
Jeg har standard edition (personal edition) lisens - så 2 gig må være max. I den server jeg har nu er der som sagt 1 gigabyte - ifølge windows task manager bruger den ikke noget nær halvdelen af det ram den har til rådighed, men det er måske fordi der ikke er plads til HELE tabellen i RAM-lageret!?
Jo mere ram jo bedre, siger man normalt. Men I dit tilfælde kan det ikke betale sig at smide mere end max 3GB i maskinen, da dit operativsystem ikke understøtter mere end max 3GB. Hvis du har større kørsler der skal afvikles jævnligt direkte på serveren er 3GB en god ide, men hvis det er en normal arbejdsdatabase hvor hovedparten af forespørgslerne køres fra klienterne så er de 2GB rigelig. SQL server har jo den heldige/uheldige egenskab at den tager alt den hukommelse den kan få, så med mindre du selv sætter en grænse i SQL så tager det alt.
Rew har ret mht 3 GB grænsen og mht SQL Servers preallokering af tilgængelig ram. Man bør gå ind og sætte maks ram i SQL Server så der efterlades fx 100 MB til OS og andet på serveren (hvis man har en IIS eller Exchange på samme boks skal man også sætte en minimum ram til SQL Server).
SQL Server preallokerer som nævnt den tilgængelige ram (dvs giver OS besked på, at den kan finde på at bruge det) og bruger så af det efterhånden. Den frigiver faktisk aldrig ram - men den allokerer altså heller ikke mere ram end den reelt har brug for!
Så selvom man plejer at sige at "mere ram er altid godt" - så er det en sandhed med modifikationer.
Hvis du kigger i sysobjectcache kan du se hvor mange ram pages (64Kb per page) sql server anvender og til hvad (der er lidt sql til brug mod tabellen i min artikel "MsSQL: Performance tuning og metadata" - og kig også i Books Online for nærmere beskrivelse af tabellen)
Hvis du vil tvinge SQL Server til at låse en tabel i ram, så kan du godt gøre det - men det er ikke sikkert at det er en fordel! Generelt bør man lade SQL Server selv vælge hvad den vil bruge ram til - bl.a. fordi den i mange tilfælde ikke læser data fra tabellen - men kun fra allerede indlæste indeks, og dermed opnår bedre performance.
Men som sagt, du kan låse en tabel i ram ved at "pinne" den:
dbcc pintable (database id, tabel id)
id værdierne får du nemmest ved at slå op i mindatabase.dbo.sysobjects og master.dbo.sysdatabases - bemærk lige at såfremt du har et clustered indeks på tabellen er det kun indekset du finder i sysobjects.
Låser du tabellen i ram ryger du også ud i, at fx sorteringer og joins måske ikke længere kan foregå i ram, men skal ske på disk. Dermed vil låsningen af en tabel i ram kunne give dårligere performance - men så har du til gengæld grund til at få mere ram i maskinen :-)
Ram, CPUer og diskes hastighed og antal samt netkorts hastighed skal altså gå op i en højere enhed - blot at fylde op i den ene ende giver ikke nødvendigvis bedre performance.
Jeg kan se at det er meget individuelt hvor meget ram man skal bruge... men hvor ser jeg hvad den allokerer nu? Jeg synes ikke at jeg kan finde de ting i nævner noget sted :s
Jeg er ikke helt sikker på hvordan det skal tolkes... help please?
I mine egenskaber for databasen kan jeg ikke se hvor meget den bruger... kan godt finde hvor man indstiller det, men kan ikke se hvad den bruger lige nu :/
jo, det er også det jeg tolker det til... men ifølge det første billede bruges alt dette ikke (kan ikke huske om memory usage history er swap-fil medregnet).
Hvis din database "kun" fylder totalt ca. 1.5 GB, så vil jeg mene at du maksimalt har brug for et par hundrede MB til caching + det løse + memory til låse.
Hvis du IKKE ser megen eskalering af låse, så hvorfor forøge memory forbruget.
Hvis du ser et meget kraftigt CPU forbrug fra din SQL server, så kan det være fordi den bruger megen tid på sorteringer. Har du kikket på hvordan din SQL bliver udført ?
arne_v - Jeg er langt fra enig med dig i, at der vil være mærkbar effekt af at øge memory i serveren, med så lille en database - Jeg har databaser på 10 gange den størrelse der performer glimrende med 1GB - Det er altså en misforståelse af mere ram automatisk giver bedre performance, det kommer altså an på om man har brug for det, og det kan man faktisk godt måle sig frem til.
Hvis der skal gives point til dette svarene til dette spørgsmål (hvilket jeg IKKE mener der skal - Der var jo ikke nogen helt korrekte svar), så er det bedste svar efter min mening det fra trer.
En helt anden ting er, at IIS og SQL på samme server er en meget dårlig ide, idet de begge vil kæmpe om resourcer.
Selve databasen fylder lidt over 3 gigabyte. Den største tabel er dog alene på omkring 1½ gigabyte. De andre tabeller er forholdsvist små i forhold til.
Der er ikke den store kamp om ressourcerne... den smule IIS bruger er ikke et problem; der er MANGE databaseopslag på hver side, og det er dem som trækker på ressourcerne.
Der er mange sorteringer... kan ikke helt sige hvor mange.
Mht sorteringer - sikr at dine sorteringer er understøttet af indeks - dvs sørg for indeks på order by, group by, distinct og join / where betingelser.
Og check som sagt tabellen master.dbo.syscacheobjects - den har en kolonne "pagesused" du kan benytte til at finde det aktuelle ramforbrug.
Sidst - hvis du ikke har sat både en min og en max ram på din IIS og SQL Server så VIL de slås om memory fordi begge services forsøger at allokere al ram. Larildsen har absolut ret mht at web- og database server på samme maskine bør undgås.
Mine indexes er sat op så de skulle fungere optimalt... vha. profiler etc... som undersøger hvad der er mest brug for.
Jeg har kigget i den tabel du siger... ved ikke hvad det er jeg skal hive fat i, men med koden: SELECT SUM(pagesused) AS Expr1 FROM syscacheobjects fik jeg resultatet 28983 jeg ved ikke om det er dét der skulle bruges.
Der er ikke sat min og max ram på IIS eller SQL server... men når jeg kigger i task manager bruger IIS ikke noget særligt ram. Er det stadig et problem så?
Ah... Bemærk lige, at profiler ikke nødvendigvis giver et retvisende billede!
Views og lignende strukturer (sp'er og funktioner) bliver ikke opløst og indgår ikke i dens vurdering - og der er et problem såfremt du har indeks der dækker multiciple kolonner.
Lige hurtigt - pages used giver ca. 231 mb ram brugt (8 kb pr page) - det lyder ok som øjebliksbillede.
Overvej om du skal ændre antal kb der sættes af som default til hver query - standard er 1024 kb, men den kan ofte sættes ned til 512 kb uden at performance falder - og det frigiver en del ram ved mange samtidige små queries.
Og prøv at tilføje kolonnen "Page Faults Delta" til din taskmanager process view - hvis den kolonne står og hamrer op og ned så swappes der - små udsving er ok, men kolonnen bør det meste af tiden stå på 0.
Personligt tror jeg ikke du vil få meget ud af at sætte en ekstra gb ram i - men uden at have hænderne på serveren er det naturligvis kun et gæt.
PF Delta står hovedsageligt på nul, hopper op til 8 ind imellem - og så til omkring 150 hvert 10'ende sekund eller noget... Ved ikke helt om det er meget eller lidt.
Hvis det er kontinuerligt så er det sådan lidt bob bob - men det er normalt at den svinger lidt.
Du kan også tilføje Virtual Memory Size for at få et fuldt billede af hvad hver enkelt process allokerer af ram (VM Size indbefatter ram swappet til disk svjh).
Prøv at sætte en maks grænse for sql servers ram forbrug så der efterlades mindst 100 mb til andre apps - det er generelt en god ting at have gjort.
Mange tak for hjælpen! Jeg prøver til at starte med med én gigabyte ram, og ser hvad der sker... Jeg vil samtidig kigge lidt nærmere på jeres forskellige forslag til at optimere serveren mht. ram.
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
