MySQL-server optimisering hardware/software

[nomore]

Hei!

 

Har en tabell hvor det pr i dag ligger omtrent 4500 linjer. Dette antallet økes med ca 4000 linjer pr måned. Innen utgangen av året vil eg annta at det foreligger ca 30000 linjer.

 

Problemet pr i dag er hastighet. Disse dataene blir lastet opp i ei nettside på ca 500 linjer om gangen, hvor det blir foretatt en beregning pr linje, i tillegg til at det blir hentet data fra andre tabeller også, via join.

 

Når denne siden vises, ligger mysql og sluker hele prosessorkraften, samt 10% av minnet.

 

Maskinen som står her er en VIA C3 1GHz med 512MB DDR og 40GB disk(IDE).

Det er ikke nødvendig å si at denne er underdimmensjonert?

 

Maskinen var i utgangspunktet kun satt der for testing og utvikling i startfasen, som nå er over.

 

Og derfor skal eg nå sette en ny maskin der. Hva mener dere er viktigst? CPU, minne eller harddisk?

Slik eg ville dimmensjonert det nå, er AMD 64bit Athlon 3200+, 2GB minne, 80GB S-ATA disk. Forslag?

[Frank2004]

4 500 rader, eller 30 000 for den saks skyld, er ingenting. Jeg vil tro du gjør et eller annet rart enten i programmet ditt, databasen, eller begge.

 

Kjører du en ny spørring for hver av de 500 linjene du henter ut? Prøv heller å lage en spørring som kan hente ut alle dataene du er interessert i på en enkelt linje -- altså bare 1 spørring pr. side.

 

Når du har fått dette i orden kan du prøve å legge inn indekser på kolonnene som brukes i spørringene. Kanskje ikke viktig før du får noen 100K rader, men skader ikke heller.

 

Når det gjelder minne bør en database tunes slik at den bruker bruker mest mulig. Du må jo selvsagt ikke la det gå utover andre programmer, men evt. web-server o.l. bruker ikke så veldig mye ram.

Endret 18. august 2005 av Frank2004

[nomore]

Takk for svaret

 

Nei, eg mener også den burde takle noen rader, men nå er maskinen noe

underdimmensjonert, så eg lurer litt

 

Slik er forøvrig spørringen:

"SELECT * FROM tabell1 LEFT JOIN tabell2 ON (tabell1.ID=tabell2.ID) WHERE (Dato>='$FraDato 00:00:00') AND (Dato<='$TilDat
o 23:59:59') AND (Slettet=0)" + ekstra where klausuler + "ORDER BY $SortBy $SortOrder"

Noe som burde være enkelt nok.

 

Eg har nå bestillt deler til ny maskin uansett, da arbeidsoppgavene bare vil bli

større etterhvert. Og dette er hva eg har bestillt:

- 1stk Chieftec 19" 2U UNC-210S-B 360W-ATX

- 1stk ABIT AS8 LGA775 I865PE 800FSB S-ATA

- 1stk Intel P4 3200 540J LGA775 800FSB BOXED

- 2stk Seagate Barracuda 7200RPM 80GB S-ATA NCQ

- 2stk Kingston ValueRam 1GB PC400 CL3

 

Og dette bør være bedre, og holde for øyeblikket.

 

Men forøvrig har eg begynnt å se etter problemer andre steder.

Kan være nettverksproblemer som gjør dette.

Endret 18. august 2005 av nomore

[nomore]

For å nevne RAID, så støtter dette hovedkortet 0 og 1, og eg har tenkt å velge 1

pga sikkerhet. Eller ville dere valgt 0 pga hastighet? Det vil også i fremtiden

kun være mysql den skal kreve mye av.

 

Er det ellers noen kommandoer el. som kan kjøres på nattetid, eller

så kaldt off-peak, som organiserer og optimerer mysql bedre?

 

For å nevne det, eg har mye erfaring med mysql hva programmering og spørring

anngår. Når det gjelder optimisering og tweaking har eg nok skulket timene noe.

Endret 18. august 2005 av nomore

[Ueland]

30k rader i en database er lite, du bør heller se på kjøretiden på spørringene.

 

Og ikke minst; nok minne er bedre enn all verdens RAID, så det er meget viktig at det er nok minne, slik at databasen får plass i minnet.

(det vil merkes som dag og natt)

 

For å se eksakt hvor mye minne som du bør ha som et minimum åpner du mappen som fysisk inneholder databasen og se hvor stor plass alle filene tar.

 

Den maskinen bør nok fint kunne klare å dra unna trafikken, men vil tro at det er minnet som er problemet.

 

Ellers kan du og gjøre følgene:

-Optimalisere alle tabellene

-tweake selve mysql konfigurasjonen

-forbedre SQL syntaxen/hentingen, caching er en fin bil.

[nomore]

30k rader i en database er lite, du bør heller se på kjøretiden på spørringene.

 

Og ikke minst; nok minne er bedre enn all verdens RAID, så det er meget viktig at det er nok minne, slik at databasen får plass i minnet.

(det vil merkes som dag og natt)

 

For å se eksakt hvor mye minne som du bør ha som et minimum åpner du mappen som fysisk inneholder databasen og se hvor stor plass alle filene tar.

 

Den maskinen bør nok fint kunne klare å dra unna trafikken, men vil tro at det er minnet som er problemet.

 

Ellers kan du og gjøre følgene:

-Optimalisere alle tabellene

-tweake selve mysql konfigurasjonen

-forbedre SQL syntaxen/hentingen, caching er en fin bil.

Rettelse fra tidligere, det er kun 256MB i maskinen.

 

Minne vil nå økes betraktelig fra 256MB til 2GB. Og fra DDR333 til DDR400.

Ved å kjøre "top" når belastningen er verst viser mysql bare at den bruker ca

10% av minnet, men 99% av CPU. Ved å sjekke mappene har disse et

diskforbruk på ca 2MB pr i dag.

 

Optimalisere tabellene vil eg nok ta en titt på ja, men her venter eg til ny maskin

er på plass, samme med mysql konfigurasjonen.

 

SQL-spørringene er for tiden under lupen, skal bla fjerne * til fordel for å kun

hente de feltene eg trenger.

 

Caching er nok en ting som eg har oversett litt

 

Og takk for all hjelp

[Ueland]

Det er ikke et problem og hente ut * fra tabellene, det er å finne de feltene som skal vises som tar tid...

[nomore]

Så du mener det er kjappere å bruke * en felt1, felt2, osv?

 

Hmm... trodde alltid det var omvendt.

[Frank2004]

Slik er forøvrig spørringen:

"SELECT * FROM tabell1 LEFT JOIN tabell2 ON (tabell1.ID=tabell2.ID) WHERE (Dato>='$FraDato 00:00:00') AND (Dato<='$TilDat
o 23:59:59') AND (Slettet=0)" + ekstra where klausuler + "ORDER BY $SortBy $SortOrder"

Noe som burde være enkelt nok.

Hmm.. Selv mysql har sikkert en eller annen måte å la deg benchmarke, eller kanskje t.o.m. forklare akkurat hva den gjør med, denne spørringen.

 

AFAIK kan ikke mysql bruke mer enn en index pr. tabell i samme spørring, så den må nok gjøre en full table scan her (noen grunn til at du ikke bruker en skikkelig database, forresten?), men med 4500-30k rader skulle ikke det gjøre noe særlig. Ale data får vel _fint_ plass i minne, regner jeg med..?

Endret 19. august 2005 av Frank2004

[Frank2004]

Så du mener det er kjappere å bruke * en felt1, felt2, osv?

 

Hmm... trodde alltid det var omvendt. 

Det er det å plukke de riktige radene som vanligvis tar mest tid i en database, og er viktig å gjøre raskt.

 

Lønner seg nok å ikke velge flere kolonner enn du faktisk skal bruke heller, men besparelsen her blir først og fremst på io/båndbredde mellom server og klient.

[Ueland]

MySQL kan fint bruke flere indekser per tabell i en spørring, så at MySQL er dårlig pga det blir litt feil. Men en diskusjon om hvem som mener at hvilket databasesystem som er best kan man ta i en egen diskusjon, dvs ikke her.

 

Bare for å få frem postene i f.eks denne tråden slår MySQL på 2 indekser i en spørring.

 

nomore: Jeg sier ikke at det er kjappere, uansett hva du skriver i SELECT delen så er det like raskt. Du henter ut data fra x rader i databasen, og MySQL må finne hvilke rader som skal vises, og det er det som tar tid, for når den først har funnet radene så har den jo alle feltene "klar"..

Endret 19. august 2005 av Ueland

[Frank2004]

MySQL kan fint bruke flere indekser per tabell,

Les hva jeg skriver..

[Ueland]

"MySQL kan fint bruke flere indekser per tabell i en spørring"

 

oppdaterte innlegget litt

[Frank2004]

"MySQL kan fint bruke flere indekser per tabell i en spørring"

 

oppdaterte innlegget litt

Oki.. Prøv å sørge for at det du skriver er riktig også, så blir det bra

 

http://groups.google.no/group/no.it.databa...de=source&hl=no

 

Edit: fikset litt på linken

Endret 19. august 2005 av Frank2004

[Ueland]

Da har jeg misforstått det litt ja

 

Men det fører ikke til at spørringer blir direkte mye (les:merkbart) tregere, og det bør hvertfall ikke være et problem på en tabell med så få rader..

[Frank2004]

Da har jeg misforstått det litt ja

 

Men det fører ikke til at spørringer blir direkte mye (les:merkbart) tregere, og det bør hvertfall ikke være et problem på en tabell med så få rader..

Neida, åpenbart at fyren gjør noe annet som er helt på jordet.

[nomore]

Anntar at den fyren du prater om er meg?

 

Joda, noe er galt, da oppslag på 300-400 rader tar ca 1-1,5 minutt.