Bruker mssql mye ram ?

[RulleRimfrost]

Sliter med ytelse på en database. Ser at den største tabellen innholder ca 8 millioner poster, size ca 6 gig (db er litt over 14 gig totalt) og denne tabellen har en index som er nesten 2 gig.

Det jeg lurte på, er det noen tommelfinger-regel for hvor mye minne en mssql-server bør utstyres med ? Laster de for eksempel inn hele tabeller i minne ?

[kaffenils]

Sliter med ytelse på en database. Ser at den største tabellen innholder ca 8 millioner poster, size ca 6 gig (db er litt over 14 gig totalt) og denne tabellen har en index som er nesten 2 gig.

Det jeg lurte på, er det noen tommelfinger-regel for hvor mye minne en mssql-server bør utstyres med ? Laster de for eksempel inn hele tabeller i minne ?

6990242[/snapback]

 

Ja, SQL Server cacher data i tilgjengelig minne, men det er mer en data som sluker minne; connections, locks, åpne inderex og tabeller f.eks.

 

Jeg kjenner ikke detaljene rundt hvordan SQL Server hånderer minnet, men mine erfaringer tilsier at for lite minne ofte er det som gir dårlig ytelse.

[roac]

Ja, SQL Server cacher data i tilgjengelig minne, men det er mer en data som sluker minne; connections, locks, åpne inderex og tabeller f.eks.

 

Jeg kjenner ikke detaljene rundt hvordan SQL Server hånderer minnet, men mine erfaringer tilsier at for lite minne ofte er det som gir dårlig ytelse.

6990660[/snapback]

Nåh, jeg vet ikke hva slags servere du jobber med (eller hvor store databasene er), men jeg synes nå at det er disk-io som er det kritiske. En SQL Server trenger ikke nødvendigvis ekstreme minnemengder, en server med 2-4GB ram klarer å kjøre selv relativt store databaser (i norsk målestokk).

 

Men som sagt, ja SQL Server bruker det den kan få av minne, og trives selvfølgelig best med så mye minne som mulig (som alle andre databaseservere jeg kjenner til).

[kaffenils]

Så kan du spørre deg om overbelastning av disk-IO skyldes for lite RAM slik at data alt for ofte må leses fra disk istedet for a buffres i minnet.

 

Men for all del, jeg er enig i at for dårlig konfigurerte disksystemer også er en av de viktigste årsakene til dårlig performance.

Endret 3. oktober 2006 av kaffenils

[RulleRimfrost]

Raid er nok planlagt mer etter redundans enn ytelse da det er prod.system for 3-4 brukere. En Proliant dual Xenon 2.8 med 1 gig ram. Tenker jeg bare prøver med et par gig ekstra i morgen, og ser hvordan den reagerer...

[roac]

Så kan du spørre deg om overbelastning av disk-IO skyldes for lite RAM slik at data alt for ofte må leses fra disk istedet for a buffres i minnet.

 

Men for all del, jeg er enig i at for dårlig konfigurerte disksystemer også er en av de viktigste årsakene til dårlig performance.

6992720[/snapback]

Det er klart, hvis du i hovedsak gjør uthentinger av data, men i systemer hvor det skjer mye oppdateringer kommer du ikke utenom disk io, transaksjoner MÅ skrives til disk når de committes, go dermed er du like langt uansett hvor mye minner du hiver inn. Men for all del, for databaser med store mengder oppslag vil det være anbefalingsverdig med såpass mye minne at i det minste alle indeksene ligger i minne.

[kaffenils]

Det er klart, hvis du i hovedsak gjør uthentinger av data, men i systemer hvor det skjer mye oppdateringer kommer du ikke utenom disk io, transaksjoner MÅ skrives til disk når de committes, go dermed er du like langt uansett hvor mye minner du hiver inn. Men for all del, for databaser med store mengder oppslag vil det være anbefalingsverdig med såpass mye minne at i det minste alle indeksene ligger i minne.

6996331[/snapback]

 

De aller fleste systemer har har en mye større andel lese- enn skriveoperasjoner. Det skrives selvfølgelig til transaksjonsloggen umiddelbart ved commit, men det betyr ikke at selve dataene skrives til disk med en gang. Det skjer kun ved checkpoints, eller hvis nye data må leses til cache og minnet er fullt.

 

Å plasserer transaksjonslogg på et eget diskvolumn, helst 0+1/1+0 RAID, kan selvfølgelig har stor effekt på performance.

 

Uansett er performance tuning såpass komplekst at det ikke går ann å si at det hvis en bare putter nok minne eller disk i serveren så går alt bra (hvis en da ikke har så uendelig mye penger at en kan kjøpe det verste av det verste).

[roac]

Uansett er performance tuning såpass komplekst at det ikke går ann å si at det hvis en bare putter nok minne eller disk i serveren så går alt bra (hvis en da ikke har så uendelig mye penger at en kan kjøpe det verste av det verste).

6996433[/snapback]

Vi er nok i bunn og grunn ganske så enige, men det kan hende vi bruker litt forksjellig metodikk eller har litt forskjellige databaser vi jobber med Tuning er umåtelig interessant, og man kan virkelig grave seg ned. Hvis det er noen som ikke er klar over det så er Kimberly Tripp helt konge (ehh... dronning) når det gjelder tuning på SQL Server, så seminarer med henne kan anbefales på det varmeste.

[kaffenils]

Hvis det er noen som ikke er klar over det så er Kimberly Tripp helt konge (ehh... dronning) når det gjelder tuning på SQL Server, så seminarer med henne kan anbefales på det varmeste.

6996491[/snapback]

 

Hadde ikke hørt om henne før nå, men jeg ser hun har skrevet mange artikler på nettet. Får prøve å få meg meg et seminar hvis hun kommer til Norge.

 

Takk for tipset

[blackbrrd]

For maks ytelse burde du ha mulighet til å cache alle mye brukte indekser i ram. Alternativet er at disse må leses konstant noe som er svært disk intensivt.

 

hmm.. allerede nevnt av roac

 

Poenget med å få plass til indeksene i ram er for å redusere disk i/o ved rene søk/spørringer til et minimum.

 

Ytelsesøkningen ved å ha plass til indeksene er vel i ordenen 10-1000x, det kommer an på hvor lite av indeksene som ble cachet i utgangspunktet og hvor mye indeksene blir brukt.

 

Det er vel også slik at det koster mye mindre å oppgradere ram enn harddiskene Kjøpte for 6-12mnd siden 4gb ddr2 ecc/reg ram for 4000kr + mva. For samme prisen hadde jeg fått to gode scsi disker

 

En database bruker så mye minne den får lov til å bruke, har den plass til å cache hele databasen med hud og hår (indekser og tabelldata) så gjør den det. Hva den faktisk cacher kommer an på bruken, men i utgangspunktet så blir alt av indekser cachet - ihvertfall de som brukes til noe fornuftig.

 

Tabeller blir forsåvidt cachet disse også, men så lenge du ikke gjør søk på uindekserte kolonner og ikke skal ta ut rene rapporter så spiller det ikke så stor rolle at selve tabellen ikke er cachet.

 

Har selv en database på ca samme størrelse som trådstarter med tilsvarende største tabell og har 6gb ram og 2stk 2,8ghz xeon prosessorer. Harddiskytelse er egentlig aldri et tema pga bra caching. Bedre prosessorytelse enn det jeg har får du med en x2 3800+ til 1500kr.

 

Oppsummert: i en "normal" database (100:1 forhold mellom lese og skriveoperasjoner) kan du glemme alt av optimalisering inntil du har nok ram. Dette gjelder også databaser med mye skriveoperasjoner fordi hvis du har for lite ram så tar lesingen av indekser fra disk altfor mye i/o tid.

 

Tuning er noe man kan tenke på etter at man har satt nok ram i serveren, det er ihvertfall min erfaring.

 

... samtidig må jeg si at man får veldig mye igjen for f.eks å sjekke alle spørringer som tar mer enn 1-5 sekunder å kjøre. Hvis disse blir kjørt ofte kan det fullstendig ødelegge ytelsen for hele systemet. Av og til må man redesigne databasen for at de skal fungere - dvs kunne hente ut relevante data på akseptabel tid.

 

Men nok en gang, uten nok ram så vil ikke all verdens tuning hjelpe*

 

*(tuning kan hjelpe til å senke mengden ram som er nødvendig)

 

Jeg har forresten mesteparten av min nyere erfaring fra PostgreSql og Linux og systemet går fint så lenge wa (tid brukt på å vente på i/o) er noen prosent, og systemet går aldri fint når wa ligger på 50%

Endret 9. oktober 2006 av blackbrrd

[Ueland]

Min erfaring fra MySQL er at systemet skal ha nok minne til å ha hele databasen (hele ruklet) cachet i minnet, samt så mye av indeksene som mulig i MySQLs internminne.

 

Med en gang det ikke er tilfellet vil alt bli tregt og spørringene tar veldig mye lengre tid. (så vokser køen av trafikk og alt bare dør).

 

Dette med å ha diskdata i cache er strengt tatt elementær databruk så vil egentlig tro at det gjelder for alle databasesystemer

 

Disk er og blir ufattelig tregt.

[roac]

Min erfaring fra MySQL er at systemet skal ha nok minne til å ha hele databasen (hele ruklet) cachet i minnet, samt så mye av indeksene som mulig i MySQLs internminne.

7046586[/snapback]

Dette er nok mye mer vesentlig for MySQL (i hvert fall noen av motorene) enn andre databaser, og har i seg selv ingen ikke med minnebruk å gjøre, men dårlig håndtering av låsing. Dette fører til at MySQL kan "henge" når den venter på disk, siden all låsingen foregår på tabellnivå. Microsoft SQL Server, Oracle, PostgreSQL og andre låser gjerne på rad eller page-nivå, som gjør at andre operasjoner fortsatt for lov til å gå mens en bruker venter på data fra disk, og man opplever ikke den samme graden av tidsforsinkelse som man gjør fra MySQL.

 

Ellers er jeg selvfølgelig enig i at disk er tregt sammenlignet med minne, men i databasesammenheng opplever jeg ofte at man MÅ ta hensyn til hvordan diskløsningene jobber, enten fordi man har store mengder data eller store mengder oppdatering av data som skal logges, og da nytter det ikke nødvendigvis å løpe å kjøpe mer minne. Det kan bedre situasjonen noe, men det er fremdeles andre begrensende faktorer. Jeg vil få nevne at det typisk er noen få GB med minne i databaseserverene som kommer godt ut (transaksjoner pr $) i TPC-målinger, men til gjengjeld har de en diskløsning som spytter godt unna. Disk er utrolig viktig, og det er en god del operasjoner i Microsoft SQL Server som fører til diskaktivitet, av sikkerhetsmessige hensyn. Det inbefatter (som tidligere nevnt) all innsetting og oppdatering av data (forutsatt recovery model forskjellig fra simple).

[blackbrrd]

Nok en gang er jeg enig med roac, har en database på ca 15gb og har 6gb ram i serveren og det går bra. Kjørte en stund med 2gb men etterhvert ble det for lite.

[RulleRimfrost]

Denna forrige løste seg nesten med 3 gig ram og korrekt indeksering, så jeg dytter inn totalt 7 gig. Den har en svært høy frekvens på oppslag, og brukerne slår gjerne opp utenom indeks... At den bruker lang tid på skriving betyr ikke så mye, for brukerne tror det er normalt. Det viktigste er at evt andre baser og små-applikasjoner som går på server ikke strupes i 5 minutter for at en bruker gjør et feil oppslag utenom index.

 

En annen sak jeg la merke til på en annen mssql base på den serveren, var at indeks-data ofte var større enn hele tabellen. Er det normalt, eller bør man kanskje gjøre noe ?

I MySql er det jo bare å kjøre repair på hele basen så løser alt seg.... nesten

[roac]

En annen sak jeg la merke til på en annen mssql base på den serveren, var at indeks-data ofte var større enn hele tabellen. Er det normalt, eller bør man kanskje gjøre noe ?

7048865[/snapback]

Det kommer jo helt an på indeksene. Husk at en indeks sorterer de kolonnene som er indeksert. I tillegg kommer pekeren til den page hvor sqlserver kan finne hele raden. Så med andre ord: Dersom du har tre kolonner, og for hver av disse kolonnene har en indeks (eller for den saks skyld har en indeks på alle tre kolonnene), så består dette av alle dataene sortert, samt pekere til datapages for hver eneste rad. Dette gjør at indeksen fort kan ta større plass en dataene selv. Har man i tillegg justert fill factor slik at indeksen (ved reindeksering/reorganisering) ikke fyller de forskjellige pages, så vil man i tillegg skru opp størrelsen på indeksene.

[blackbrrd]

...og brukerne slår gjerne opp utenom indeks...

 

Dette er ingen god ide hvis tabellene det blir slått opp på er store, da vil hele tabellen måtte leses inn i minne og det er i tillegg relativt tregt. Prøv så godt du kan og indekser de mest vanlige oppslagene.

 

... ikke overraskende å høre at ram løste problemet ditt forresten

[kaffenils]

En annen sak jeg la merke til på en annen mssql base på den serveren, var at indeks-data ofte var større enn hele tabellen. Er det normalt, eller bør man kanskje gjøre noe ?

7048865[/snapback]

Det kommer jo helt an på indeksene. Husk at en indeks sorterer de kolonnene som er indeksert. I tillegg kommer pekeren til den page hvor sqlserver kan finne hele raden.

 

Og i tillegg så inneholder alle indexer også hele indexen som er clustered.

[roac]

Og i tillegg så inneholder alle indexer også hele indexen som er clustered.

7093294[/snapback]

Som kan være clustered. Dersom du alltid lager primary key clustered uten å tenke deg om kan du fort gå på en smell, det er langt fra alltid clustered indexes er hensiktsmessig. Clustered indexes egner seg for tilnærmet strengt stigende eller strengt synkende verdier, men ikke for relativt tilfeldige verdier.

[kaffenils]

Og i tillegg så inneholder alle indexer også hele indexen som er clustered.

7093294[/snapback]

Som kan være clustered. Dersom du alltid lager primary key clustered uten å tenke deg om kan du fort gå på en smell, det er langt fra alltid clustered indexes er hensiktsmessig. Clustered indexes egner seg for tilnærmet strengt stigende eller strengt synkende verdier, men ikke for relativt tilfeldige verdier.

7094593[/snapback]

 

Mulig jeg forklarte meg dårlig. Det jeg mente er at hvis tabellen har en clustered index (trenger ikke å være primary) så vil verdiene i denne indexen inkluderes i alle andre indexer.

 

Dvs. at hvis du har en tabell med kolonnene ID og Navn og ID har en clustered index (index_1) så vil en index på kolonne Navn (index_2) også inneholde ID.

Hvis du da f.eks. kjører select ID, Navn from Tabell where ID=1 så har SQL Server alle verdiene den trenger i indexen for Navn (index_2) og trenger derfor ikke å slå opp data i selve tabellraden for å hente ut ID.