Databaseserver - ytelse med Solid State Disks

[N_R]

Hei,

 

skal sette opp en database- og webserver som kan få en del trafikk etterhvert. Samtidig ser man jo nå at SSD ("flash-disker") snart er å få tak i, hvor søke tiden er 0,1xxx ms, istedet for 10+ ms. Er ikke noe mattegeni, men vil tro 100x raskere søketid vil kunne hjelpe ganske så bra....

 

Ideelt sett ønsker jeg nemlig å kjøre et VMWare lag i "bunnen" og en eller to viruteller servere oppå, men har unngått dette nettopp pga at IO er største bremsen i et virtuelt oppsett.

 

Databasen blir ikke nevneverdig stor så jeg trenger ikke mye plass, og alt annet av content henter jeg fra et standard RAID-oppsett allikevel. Er altså kun et spørsmål om man skal bytte ut en 36GB, 10k SCSI-disk med en 32GB SSD.

 

Noen som vet mer om dette, har sett ytelsestall osv osv? Er det noen drawback som hurtigere slitase, større sjanse for feil, osv ? Hvis ikke tror jeg SSD er svaret på drømmene til mange av oss

[Wraith]

Noen som vet mer om dette, har sett ytelsestall osv osv? Er det noen drawback som hurtigere slitase, større sjanse for feil, osv ? Hvis ikke tror jeg SSD er svaret på drømmene til mange av oss 

7720097[/snapback]

 

Var på et seminar om SSD-disker for 2 års tid siden, så at det var god ytelse der. Når det gjelder slitasje så slites de jo kanskje raskere, men SSD-disker kan også settes i RAID, slik at man unngår noe datatap, og også øker ytelsen mer.

[blackbrrd]

Harddisk = 8ms søketid

SSD = 0,1ms søketid

RAM = 0,00005ms søketid

 

Mao, å hente noe fra ram går 2000 ganger raskere fra ram enn fra SSD.

 

Så sant du ikke har en veldig spesiell database med masse skrive operasjoner istedetfor de vanlige 99% leseoperasjoner så vil du se liten nytte av SSD. Databasen vil kun være kjapp hvis så å si alt av indekser og ofte brukte data ligger i ram.

 

Har endel erfaring med å få en 50gb database til å ha bra ytelse. Har vel ca 5x bedre ytelse med 10gb ram enn med 6gb ram, ettersom med 6gb ram så ble noen av indeksene hevet ut av minnet og måtte leses inn fra disk etterpå... Prosessorytelse har lite med saken å gjøre, bare så det er nevnt, dette kjøres på en dual 2,8ghz xeon (netburst 512kb l2 cache).

 

Hvis vi skulle trenge mer ram så kommer jeg til å kjøpe en maskin med minst 16 ram slotter, ettersom 4gb ram brikker er uforholdsmessig dyre... Den vi har idag har kun 6 ram slotter, og det er fyllt opp nå.

 

*Målt tilgangstid, spesifikasjonene er på noe sånt som 5ns ref: http://www.anandtech.com/cpuchipsets/showd...spx?i=2548&p=12

Endret 20. april 2007 av blackbrrd

[roac]

SSD er langt kjappere enn tradisjonelle harddisker, en 2,5" SSD rapporteres å kunne håndtere 7000 io/sek ved 512kB blokker. For 8kB blokker vil jeg da regne med snaue 1000, noe som er langt over de 160-180 som en 15k disk vil klare. Men, la meg også poengtere et annet meget godt poeng, varmeutvikling. En 2.5" SSD bruker i underkant av 1W ved diskaktivitet, mot for 4-5W for en 2.5" standard SAS disk, og 10-15W for en 3.5". Dette vil potensielt kunne utgjøre en hel del i et serverrom.

Endret 16. juni 2007 av roac

[wsp]

Hva med antall overskrivninger?

Leste et sted at SSD-diskene er på samme nivå som industrial CF, og de kan vanligvis overskrives et par mill ganger.

 

Hvis dette er tilfelle på SSD-disker så vil levetida avhenge av hvilken type workload du belaster den med. Hvis det i hovedsak er leseoperasjoner vil man klart ha store fordeler med SSD.

[mrs.robinson]

Noen som vet mer om dette, har sett ytelsestall osv osv? Er det noen drawback som hurtigere slitase, større sjanse for feil, osv ? Hvis ikke tror jeg SSD er svaret på drømmene til mange av oss 

7720097[/snapback]

 

Harddisk = 8ms søketid

SSD = 0,1ms søketid

RAM = 0,00005ms søketid

 

Mao, å hente noe fra ram går 2000 ganger raskere fra ram enn fra SSD.

 

Så sant du ikke har en veldig spesiell database med masse skrive operasjoner istedetfor de vanlige 99% leseoperasjoner så vil du se liten nytte av SSD. Databasen vil kun være kjapp hvis så å si alt av indekser og ofte brukte data ligger i ram.

 

Har endel erfaring med å få en 50gb database til å ha bra ytelse. Har vel ca 5x bedre ytelse med 10gb ram enn med 6gb ram, ettersom med 6gb ram så ble noen av indeksene hevet ut av minnet og måtte leses inn fra disk etterpå... Prosessorytelse har lite med saken å gjøre, bare så det er nevnt, dette kjøres på en dual 2,8ghz xeon (netburst 512kb l2 cache).

 

Hvis vi skulle trenge mer ram så kommer jeg til å kjøpe en maskin med minst 16 ram slotter, ettersom 4gb ram brikker er uforholdsmessig dyre... Den vi har idag har kun 6 ram slotter, og det er fyllt opp nå.

7720589[/snapback]

 

Såvidt jeg har skjønt så vil et oppsett med SSD og virtualisering tjene mye på høy IO.

 

Vi må ikke glemme at svære organisasjoner har kjørt databaser på SSD i mange år alleredel. Typisk innenfor finans og forskning. Ville disse gjort dette uten økt ytelse? Tvilsomt. Og gevinsten vil øke proposjonalt med antall spørringer/brukere.

[blackbrrd]

Ytelsen vil øke proposjonalt med antall SKRIVE operasjoner isåfall, lese-operasjoner må caches i RAM for å få noe som minner om ok ytelse.

[roac]

Ytelsen vil øke proposjonalt med antall SKRIVE operasjoner isåfall, lese-operasjoner må caches i RAM for å få noe som minner om ok ytelse.

8883894[/snapback]

Ikke helt enig her. Du forutsetter da at det er praktisk mulig med nok RAM til å holde alt i minnet. I større miljø er det ikke praktisk mulig.

 

Men, tilbake til saken. Et sted jeg helt klart ser for meg bruk av SSD er temporary tablespaces i databaser. Der må det jo bare være HELT konge.

[blackbrrd]

Jeg forutsetter at det er praktisk mulig å ha ofte leste data i RAM, ettersom SSD er sinnsvakt tregt i forhold til RAM.

 

Som nevnt i posten ovenfor, så vil det sikkert ta 2000 ganger så lang tid å hente noe fra en SSD som fra RAM. Til sammenligning så er SDD 80 ganger raskere enn HDD-er.

 

Ser forresten for meg at for å få utnyttet bedre random-access til SSD og for å utnytte minnet bedre så er det vel ønskelig med mindre blokker?

[Fritz0r]

Prblemet med SSD disker er at selv om de er utrolig raske på loading av Windows, programmer og slikt, så suger de totalt elendig mye på kopiering av større filer, faktisk treigere en 5400 disker, så en bør vurdere bruken en skal ha på disken før en kjøper.

 

 

Tomshardware.com har større tester med flere harddisker, de hadde en test med blandt anna SSD disker nylig, sjekk og finn disken som passer ditt behov.

[roac]

Ser forresten for meg at for å få utnyttet bedre random-access til SSD og for å utnytte minnet bedre så er det vel ønskelig med mindre blokker?

8896268[/snapback]

Du har et poeng. SSD er dårlig på overføring, god på søketid. Så det vil være fordelaktig med så små blokker som mulig, men innenfor det f eks databaseapplikasjonen bruker. Så i tilfellet MSSQL (og Sybase?) vil det være hensiktsmessig med 8kB eller 64kB. Noe mindre blokker enn 8kB brukes ikke likevel. Jeg vet at andre databaser kan bruke mindre blokker, Oracle kan vel i hvert fall bruke ned i 2kB?

[roac]

Prblemet med SSD disker er at selv om de er utrolig raske på loading av Windows, programmer og slikt, så suger de totalt elendig mye på kopiering av større filer, faktisk treigere en 5400 disker, så en bør vurdere bruken en skal ha på disken før en kjøper.

8896316[/snapback]

For det første kommer det an på hva slags disk du kjøper, og for det andre så har det hele tiden vært snakk om SØKETID. Søketid er irrelevant ved lesing/skriving av store mengder sekvensielle data.

[deviant]

Ser forresten for meg at for å få utnyttet bedre random-access til SSD og for å utnytte minnet bedre så er det vel ønskelig med mindre blokker?

8896268[/snapback]

Du har et poeng. SSD er dårlig på overføring, god på søketid. Så det vil være fordelaktig med så små blokker som mulig, men innenfor det f eks databaseapplikasjonen bruker. Så i tilfellet MSSQL (og Sybase?) vil det være hensiktsmessig med 8kB eller 64kB. Noe mindre blokker enn 8kB brukes ikke likevel. Jeg vet at andre databaser kan bruke mindre blokker, Oracle kan vel i hvert fall bruke ned i 2kB?

8898324[/snapback]

 

Dette er jo litt avhengig av hvordan informasjonen benyttes av både databasemotoren og operativsystemet. En typisk problemstilling er nettop at blokkstørrelsen forandrer seg på veien fra databasemotor til lagringsenhet eller vice versa.

 

Det finnes likevel en del anledninger der blokkstørrelser mindre enn både 8k og 4k benyttes, og sikkert noen der det er ønskelig med store blokker selv om man har low latency storage.

 

Det blir uansett spennende å se hvilke anvendelser vi kan finne for SSD etter hvert som enhetene faller i pris. Når vi vet at diskbaserte lagringsløsninger med 200 spindler klarer ned mot 50 ms gjennomsnittlig responstid ved knappe 30.000 iops, gleder jeg meg til å se et fullspekket RAID med flashdisker

Endret 19. juni 2007 av deviant

[blackbrrd]

Jeg står forresten fortsatt på det at det er viktigere med mye ram enn kjappe disker i en databaseløsning - samme hvor stor den er

[deviant]

Jeg står forresten fortsatt på det at det er viktigere med mye ram enn kjappe disker i en databaseløsning - samme hvor stor den er

8900444[/snapback]

 

Ja, ofte er det det, med en del begresninger og unntak.

 

* Det begrenser seg hvor mye minne man kan putte i vanlige servere før prisen blir uoverkommelig, eller man støter på tekniske begrensninger. Tro det eller ei, men 200 lynraske disker ER billigere enn en terabyte minne per node, selv om førstnevnte gjerne runder millionen.

 

* Data skal skrives til et sted det ikke forsvinner. Skriveintensive applikasjoner har dermed langt større utbytte av raske disker enn mye minne.

 

* I en del klyngeløsninger er det ikke ønskelig med for mye data i minnet, da dette belaster cpu og interconnect.

 

* Noen ganger er det raskere å hente en bestemt blokk på disk, fremfor å bruke en stor mengde CPU på å lete gjennom dårlig indeksert minne. Dette er en tradeoff mellom CPU og IO, og det er ikke helt uvanlig at man tuner ned buffercache for å redusere CPU-belastning på bekostning av IO.

 

I gamle dager het det at man skulle ha mest mulig minne, i moderne tid skal man bare ha nok

 

Hvordan tingene løses i praksis er avhengig av applikasjonen, datasettet, databasemotoren og plattformen for øvrig - for ikke å nevne budsjettet.

Endret 19. juni 2007 av deviant

[roac]

Jeg står forresten fortsatt på det at det er viktigere med mye ram enn kjappe disker i en databaseløsning - samme hvor stor den er

8900444[/snapback]

Det kommer helt an på løsningen. Har du en løsning med begrenset mengde data og stort sett uthenting av data, så har du helt klart et poeng. Men hva med store databaseløsninger hvor det HELE tiden skjer oppdatering av data? Disse skal tross alt skrives til disk (i det MINSTE loggdisken, men plass her kan heller ikke frigjøres før dataene har havnet i databasen). Tro meg, det ER ofte behov for både nok og raske nok disker til databaser. Og erfaringsmessig vil jeg bare påpeke at dette SPESIELT er tilfelle ved dårlig skrevne applikasjoner, og vi snakker da gjerne om uvettig bruk av cursors, midlertidige tabeller, tabellvariable etc, snapshot isolation level etc. Pr i dag vil jeg kunne finne på å hevde at den "praktiske" grensen på mengde minne ofte ligger et sted mellom 16 og 48 GB, uten at det alene kan ta støyten for heftig skriving til databasen(e).

Endret 20. juni 2007 av roac

[blackbrrd]

Er litt enig med deg angående mengde minne som er mulig å få til... Pr idag så er det mest minne for pengene å kjøpe en server med 16 minneslotter og 2gb minnebrikker. Totalt 32gb minne og det kommer på rundt 70000 (sjekk f.eks nextron.no)

 

Det er selvfølgelig avhengig av hvilket type system, f.eks ser jeg for meg at systemet som håndterer transaksjoner i minibanker o.l. har god bruk for SSD. Applikasjoner som dette forumet derimot kan jeg godt se for meg at har mye mer igjen for store mengder RAM.

 

Poenget mitt er ihvertfall at du kan ikke gå ut i fra at SSD disker vil hjelpe spesiellt mye når det gjelder å lese data... Skriveoperasjoner er en annen ting. (Ref: ram 2000 ganger raskere enn SSD)

[mrs.robinson]

Ytelsen vil øke proposjonalt med antall SKRIVE operasjoner isåfall, lese-operasjoner må caches i RAM for å få noe som minner om ok ytelse.

8883894[/snapback]

 

Jeg forutsetter at det er praktisk mulig å ha ofte leste data i RAM, ettersom SSD er sinnsvakt tregt i forhold til RAM.

 

Som nevnt i posten ovenfor, så vil det sikkert ta 2000 ganger så lang tid å hente noe fra en SSD som fra RAM. Til sammenligning så er SDD 80 ganger raskere enn HDD-er.

 

Ser forresten for meg at for å få utnyttet bedre random-access til SSD og for å utnytte minnet bedre så er det vel ønskelig med mindre blokker?

8896268[/snapback]

 

Nå skal jeg ikke krangle her blbrrd. Men faktum er at med intensive I/O mot en DB vil SSD slik som SSD SAN gjør natt til dag for å si det slik. Avhengig av miljø, load og kritiske faktorer kan det for mange bedrifter faktisk svare seg å gå for slike løsninger. Som du ser er det fiber channel etc. Og her kan du kjøre inntill 128 GB ram. Tror det meste vil bevege seg kjapt da. Dette er ikke ukjent inen bank/finans.

[roac]

Nå skal jeg ikke krangle her blbrrd. Men faktum er at med intensive I/O mot en DB vil SSD slik som SSD SAN gjør natt til dag for å si det slik. Avhengig av miljø, load og kritiske faktorer kan det for mange bedrifter faktisk svare seg å gå for slike løsninger. Som du ser er det fiber channel etc. Og her kan du kjøre inntill 128 GB ram. Tror det meste vil bevege seg kjapt da. Dette er ikke ukjent inen bank/finans.

9090485[/snapback]

Det er typsisk flere faktorer inne i bildet her. Dersom det er leseytelsen du er ute etter, så kan du (sannsynligvis) likegjerne kjøpe en server med mye minne. 128GB minne i en server får du uten problemer tak i.

 

Når det gjelder skriveytelse så stiller jeg meg spørsmålet hva slags diskløsning du må ha i bakkant, eller om du er villig til å stole fult ut på et ram-basert lagringsmedium og tilhørende backup batteri/ups/aggregat, eller om du også ville skrevet til disk. I så tilfelle må du jo uansett ha en diskløsning som klarer å tygge unna.

 

Uansett, geeken i meg synes dette er veldig spennende

 

Edit: Hadde jeg sett bedre etter hatte jeg nok sett at det var non-violatile memory. Det gjør saken litt annerledes, og da kan man faktisk stole på det som lagringsmedium.

Endret 17. juli 2007 av roac

[blackbrrd]

Nå tror jeg det er noen som ikke har lest posten min grundig nok.

 

Jeg har sagt at i visse situasjoner så vil ikke SSD disker hjelpe på databaseytelsen.

 

Situasjonene er:

a) lite skriveoperasjoner

b) mulighet til å cache så å si hele working-datasettet i minne

 

How much faster is solid state disk than a hard drive?

A good hard disk drive provides access times in the 4-5 millisecond range (optimally). The RamSan has an access time of 15 microseconds. The RamSan is 250 times faster than a hard disk drive. A good hard disk drive provides 250-300 random I/O's per second. The RamSan provides over 400,000 random I/O's per second. It would take 1,333 hard disk drives to match this total I/O performance and will still have far worse data access latency.

 

15 microseconds som blir oppgitt her er det samme som 0,015ms søketid. Som nevnt tidligere har ram 0,00005 søketid. Mao er ram 300 ganger kjappere enn SSD-SAN.

 

Mao, hvis du får cachet mesteparten av working-datasettet i minne så vil systemet bruke 1/300 så mye I/O tid som hvis det må bruke SSD-SAN hver gang det skal lese noe data.

 

Why should I purchase the RamSan instead of more memory for my server?

There are several reasons that a solid state disk might be a better solution than adding memory to a server. Here are some of those reasons:

 

  1. The RamSan is non-volatile. The memory in your server is volatile meaning that it loses data if you lose external power. The RamSan preserves your data even if external power is lost.

  2. The RamSan is external to the server. If your server reboots or crashes, you will lose all data in server memory. The RamSan is isolated from server instability and preserves data even if the server reboots.

  3. The RamSan can be shared across multiple servers. The memory in your server can only be used by that server. The memory in a solid state disk can be shared across multiple servers simultaneously.

  4. With solid state disk, you never have a cache miss. In normal operating modes, your server memory is only used to cache recently read data and is worthless for really random data accesses to large data sets. With solid state disk, you never have a cache miss because the data is permanently stored in memory.

  5. Solid state disks are a more economical way to accumulate large memory capacities. The higher the memory density in your server, the more you will have to pay for it. External solid state disks are not limited by processor to memory restrictions or even space constraints like servers.

  6. The RamSan does not need to be thrown out when you upgrade your server. New generations of servers almost always require new generations of memory. Even upgrading memory in a server might require upgrading to higher densities of memory. The RamSan does not need to be modified if you upgrade your server.

  7. RamSan solid state disks provide better memory protection than most server memory.

 

Texas Instruments har også gjort endel antagelser for når du skal investere i SSD-SAN.

 

Kriteriene er bl.a.:

a) working-datasett som er for store til å ha i ram

b) det er for dyrt å kjøpe nok ram til å ha working-datasettet i ram

 

Jeg ser for meg at harddisker kommer til å bli erstattet av SSD på sikt, når prisforskjellen på de to er mindre enn den er pr idag.

 

RamSAN som det blir linket til litt lenger ovenfor (som har 15 microsekunder access tid) bruker forresten vanlig ddr ram og batteribackup...

Endret 18. juli 2007 av blackbrrd