Server til MySQL...

[russlebiff]

Hei, jeg trenger en liten, men kraftig server skal ha som hovedoppgave å håndtere en MySQL database. Usikker på hva jeg skal velge, men tenkte kanskje en kraftig Shuttle pc e.l.?

Hva gangner sql databasen best? Kraftig cpu, mye minne, rask disk?

 

Sql db'n har for tiden 2,5 mill entries, og masse trafikk. Den mottar og sender forespørsler/entries mange ganger i minuttet, ofte blir det litt 'hamring'..

 

Noen tips ?

[henningml]

Har du noen tall på qps ("queries per second")? Dersom du kjører Linux kan du installere "mytop" for å følge med på dette.

 

I all hovedsak er det minne som er viktigst for en databaseserver, samt en korrekt oppsatt my.cnf (send meg en PM så kan jeg hjelpe med den).

 

Om databasen er stor (1 GB +) kan du begynne å bekymre deg for disk-access og slikt.

 

Tipper at med en 1.5 Ghz Shuttle med 515 MB ram, at du vil klare 60 qps uten problemer, dvs grovt anslått et forum med 2-300 samtidige besøkende.

Endret 20. april 2006 av henningml

[Ueland]

Hva er masse trafikk?

Og et minutt er utrolig lenge, vi snakker sekunder når det gjelder trafikk på MySQL, som nevnt over

 

Databasen til forumet her er rundt 5GB med og ligger på en Opteron server med 8GB RAM, da MySQL vil ha hele databasen i minnet for å fungere optimalt. Har den ikke alt i minnet vil mye treghet oppstå.

 

Den tar seg av rundt 90-100 spørringer i sekundet og har forruten minnet og 4 SATA 10K RPMs raptor disker.

[russlebiff]

Vel, har ikke noen eksakte tall på antall qps, men tipper den leser/skriver til db'n ca 25 ganger i minuttet. Hver gang noe skal skrives til db'n, så søker den gjennom et felt for å sjekke om data eksistere, og hvis ikke så legger den til.

 

Har testet litt med den vanlige pc'n min, og sender jeg data til db'n (les->if no match->skriv ev. les->if match>return) hvert 1000 ms, lagger hele pc'n merkbart.. Jeg er ingen sql guru, så mulig at jeg ikke gjør det optimalt heller.

 

Har også vært inne på tanken å legge hele db'n i minnet (er snakk om ca 300 Mb), men hvordan fungerer det i praksis? Når noe endres/legges til, skrives det da både til db'n i minnet og på disken, eller blir det bare gjevnelig tatt en backup e.l.?

[roac]

Om databasen er stor (1 GB +) kan du begynne å bekymre deg for disk-access og slikt.

5953457[/snapback]

Tullball. Dette er like vesentlig uansett så lenge du bruker en ACID database (databaser som ikke tilfredsstiller kravene til ACID er uansett kun for ukritiske data, så det ser jeg bort i fra her. I en hovedoppgave BØR dataene være kritiske).

 

For en ACID-kompatibel database SKAL data skrives til fysisk disk for hver transaksjon slik at man ikke får datatap ved et evt strømbrudd. Hvilken mengde data du har er derfor totalt irrelevant, det som er relevant er antallet skriveoperasjoner som kreves i sekundet.

 

For en enkelt harddisk (og speil) gjelder her at disken bør ha så stor rotasjonshastighet som mulig, og at søketiden skal minimeres. Med andre ord, dersom du har en stor harddisk kan du øke ytelsen betraktelig på denne ved kun å ha en liten partisjon, da dette vil kunne redusere søketiden på disken (du vil aldri få fullstroke).

 

For flere disker i raid er det mer komplisert, men generelt kan man si at RAID 1+0 (10, også kjent som stripe av speil) har veldig god skriveytelse, leseytelse og sikkerhet, men koster en del. Noen billigere kontrollere støtter ikke 1+0 men i steden 0+1 (01, også kjent som speil av striper). Raid 0+1 har like gode lese og skriveytelse som 1+0, men dårligere sikkerhet.

 

Dersom kun ytelse er vesentlig, kan raid 0 (stripe) anbefales, men man skal da være klar over at man mister alle data så fort en disk ryker, og at antatt levetid for raidsettet raskt reduseres med økende antall disker.

 

Raid 5/6/7 anbefales ikke dersom skrivehastighet er vesentlig (en logisk skriveoperasjon her er flere fysiske lese-og skriveoperasjoner, noe som trekker ytelsen ned.

 

Til slutt ang disk, pass på stripestørrelsen og se den i sammenheng med blokkstørrelse på filsystem, og ikke minst hva som er anbefalt for databaseserveren. (Jeg vet ikke hva som er anbefalt for MySQL). Her kan det være mye ytelse å hente.

 

Når det gjelder minne bør 512MB være nok nesten uansett hvilken databaseserver du hadde valgt. For MySQL på linux vil jeg tro at 256MB også vil gå helt fint.

 

Sålenge du ikke velger noe rask av en prosessor vil ikke prosessoren være en hindring. Jeg ser sjelden at det er prosessorkraften som er begrensningen til en databaseserver. Dette er kanskje ikke så overraskende, siden databaser av natur jobber veldig intensivt mot minne og disk.

 

Mitt råd for å få en rask databaseserver er å spre dataene over så mange disker som mulig, og evt å bruke speiling som redundans, ikke paritet.

[henningml]

Du har mye rett her ja, men du glemmer vel en liten ting.. Brorparten av queries mot en database er somregel lese-operasjoner, ikke skriveoperasjoner. Dersom server har minne nok til å holde de mest sentrale tabeller, indekser og queries i cache vil man spare mye diskaksess, da bare updates og inserts utløser diskoperasjoner. At databasen holder indekser, queries og temporære tabeller i cache betyr ikke nødvendigvis noe for datasikkerheten.

 

Ruslebiff: Det høres ut som om kanskje tabellene dine mangler noen indekser om den sliter med å gjøre kun en select og en update i sekundet. Du kan teste query'ene dine i feks phpmyadmin så ser du hvor lang tid de tar å kjøre. De fleste normale queries burde ikke ta mer enn 0.0x sekunder. Av de grunner som Roac nevner bør ikke databasen legges direkte i minnet, men du bør gi mysql nok minne til at den cacher effektivt.

[roac]

Du har mye rett her ja, men du glemmer vel en liten ting.. Brorparten av queries mot en database er somregel lese-operasjoner, ikke skriveoperasjoner. Dersom server har minne nok til å holde de mest sentrale tabeller, indekser og queries i cache vil man spare mye diskaksess, da bare updates og inserts utløser diskoperasjoner. At databasen holder indekser, queries og temporære tabeller i cache betyr ikke nødvendigvis noe for datasikkerheten.

5959824[/snapback]

Nå, det varierer nå svært, og det kan sågar være store forskjeller inad i en en database som gjør at, f eks på Microsoft SQL Server, en del kunder velger å splitte databasen over flere filgrupper med forskjellig raidnivå. For å ta et godt eksempel, en nettbutikk. Det er begrenset med oppdatering av data mot produkttabellene, men for ordretabellene er det ganske mye skriveoperasjoner. For store løsninger som har samme problemstilling vil det kunne være hensiktsmessig å ha produktdata på et raid 5 sett, og ordredata på raid 1 eller raid 10.

 

Men, du har selvfølgelig helt rett i at cache kan lette leseoperasjoner vesentlig. Men, ang raid 10 mot raid 5, vær klar over at det skal være veldig lite skriveoperasjoner i forhhold til leseoperasjoner før du kan forsvare å bruke raid 5 (evt så lite trafikk at det ikke har noe å si). Tallet jeg som regel ser er under 10% skriving. Det er faktisk ganske mange databaser som faller utenfor dette. Merk også at dette gjelder operasjoner mot disk, det vil si at der du har godt nok med minne til at de hyppigst forespurte data ligger i minne, så blir forholdet enda verre siden det i praksis nesten ikke er lesing fra disk, som du selv påpekte.

[Ueland]

henningml: Når vi snakker databasen i minnet så mener vi at serveren har nok minne, og satt opp slik at den automatisk legges i minne så det brukes som buffer. Det er noe operativsystemet selv tar seg av for å øke ytelsen.

 

En stor mye brukt database på en server med for lite ram, mot en som har nok ram er som natt og dag når det gjelder ytelse.

 

Uansett hvordan man vender og vrir på det så er disk suppetregt, det fører til at for en server som ikke kan ha databasen i minnet må slå opp radene på disk, og det tar tid.

 

En spørring mot en tabell som ligger i minnet kan fint ta rundt 0.00X sekundet, å slå opp når man bruker disk vil spørringstiden variere veldig etter hvor mye diskaktivitet som foregår. (så når man først må på disk er det bra med et raskt oppett).

 

Å bruke heap tabeller, dvs tabeller som bare ligger i minnet er og smart i de tilfellene det er mulig. Spørringstiden da vil fint komme på rundt 0.000x sekunder.

http://sunsite.mff.cuni.cz/MIRRORS/ftp.mys...oc/en/HEAP.html

 

En annen viktig sak som fint kan sørge for tregere responstid fra MySQL er tabeller med mange oppdateringer. MyISAM tabeller har det problemet at tabellen låses ved en oppdatering, og er det mange oppdateringer vil det bli treg respons. For eksempel InnoDB tabeller har ikke det problemet siden den kun låser på radnivå.

 

Som du ser er det nok av problemer som kan oppstå

[russlebiff]

HEAP doesn't support AUTO_INCREMENT columns.

Ergo, kan jeg ikke bruke heap siden jeg har 'id' som auto inc?

 

En annen ting, burde jeg indeksere flest mulig kolonner for å øke ytelsen?

Hvis jeg f.eks bare indekserer 'id' og søker på 'adresse', vil dette være vesentlig tregere enn om både 'id' og 'adresse' er index?

[henningml]

Ueland: Ja tror det var det jeg prøvde å si, eller mener

 

russlebiff:

 

Bare bruk HEAP til session-tabeller eller andre tabeller det ikke er kritisk om du mister.

 

Ellers, legg indekser på de kolonnene du refererer til med "=" i where-clauser.

[roac]

Ellers, legg indekser på de kolonnene du refererer til med "=" i where-clauser.

5990474[/snapback]

Dette er en farlig anbefaling å komme med. Dersom du hadde sagt at det skulle gjøres på de kolonnene som ofte brukes i where-clauses så kunne jeg vært enig. For mye indeksering vil kunne redusere ytelsen på en database som har mye oppdatering.

[henningml]

Det var da svært så pessimistisk du var da.. Men du har nok helt rett, for indeksen må oppdateres dersom kolonnen som har indeks blir oppdatert.

 

Men en ting jeg lurer på;

 

Dersom man ikke har indeks på en nøkkelverdi, og gjør en mengde updates som benytter denne verdien i oppslaget, vil ikke query'ene bli forferdelig trege?

 

Hva blir tregest, å risikere å måtte oppdatere index i de tilfeller en nøkkelverdi endres (hvor ofte skjer egentlig det?), eller å gjøre oppdatering på en rad uten å kunne bruke indeks for å finne raden?

 

I det første tilfellet må indeksen oppdateres iblant, i det andre tilfellet må alle oppslag gjøres uten indeks.

 

Resonerer jeg riktig nå?

[Ueland]

Hvis det kjøres lette spørringer vil de som blir kjørt oftest bli lagt i spørringscachen til MySQL så akkurat det løser den bra selv.

 

Ikke glem at MySQL og kjører mange spørringer simultant uten problemer så det skal litt til før den starter å slite.

 

Men ja, kjøres det _mange_ updates mot en tabell det leses mot vil det kunne bli tregt.