mboost-dp1
unknown
#2 nej der gå ikke 171år inden disken går i stykker.
#3 Ja da har heltsikkert fået harddisk failure.
Læs lidt om Mean time between failure på wikipedia.
#3 Ja da har heltsikkert fået harddisk failure.
Læs lidt om Mean time between failure på wikipedia.
#1
held og lykke med at finde en bærbar der kan sluge sas diske
:D?
#10
du skal da helt ned på forbes' 4. plads over rigeste mennesker for at finde en person som i nutidens politiske ukorrekte sprog kan betegnes som "ikke hvid", i form af Prince Alwaleed Bin Talal Alsaud. og jeg vil da tro at han er mere interesseret i olie end raid diske, og i det tilfælde skal du så langt ned som en 17. plads for at finde den næste person, så jeg vil da mene der er massere af "hvide" mennesker i verden der ville ha råd.
held og lykke med at finde en bærbar der kan sluge sas diske
:D?
#10
du skal da helt ned på forbes' 4. plads over rigeste mennesker for at finde en person som i nutidens politiske ukorrekte sprog kan betegnes som "ikke hvid", i form af Prince Alwaleed Bin Talal Alsaud. og jeg vil da tro at han er mere interesseret i olie end raid diske, og i det tilfælde skal du så langt ned som en 17. plads for at finde den næste person, så jeg vil da mene der er massere af "hvide" mennesker i verden der ville ha råd.
#2
Det kan beregnes med simpelt matematik. Det er det samme som beregningerne der viser at chancen for at få 7 rigtige i Lotto er ca. 1:8.000.000
#
Kedeligt!
Var lige oppe men så ned igen... trode det var SATA, men så er det sgu det sædvanlige SCSI!
Hvornår fatter harddiskproducenterne at vi er nogle der vil betale for en 15k rpm disc til SATA.
Gider ikke betale 1000 kr eller mere for en SCSI-controller oven i de 3000 kr en 15k rpm 74GB harddisk koster!
Godt at Western Digital har deres Raptor serie... men det er jo kun 10k rpm. Må "nøjes" med min dejlige Raptor indtil videre så :-/
Det kan beregnes med simpelt matematik. Det er det samme som beregningerne der viser at chancen for at få 7 rigtige i Lotto er ca. 1:8.000.000
#
Kedeligt!
Var lige oppe men så ned igen... trode det var SATA, men så er det sgu det sædvanlige SCSI!
Hvornår fatter harddiskproducenterne at vi er nogle der vil betale for en 15k rpm disc til SATA.
Gider ikke betale 1000 kr eller mere for en SCSI-controller oven i de 3000 kr en 15k rpm 74GB harddisk koster!
Godt at Western Digital har deres Raptor serie... men det er jo kun 10k rpm. Må "nøjes" med min dejlige Raptor indtil videre så :-/
ARGH da jeg læste denne nyhed tænkte jeg med det samme "nu er der sikkert flere der tror de skal smide denne enterprise disk i deres laptop..." ARGH igen
#6 den er nok heller ik lavet til "generel lagring"... Ligesom en raptor ikke fås i store størrelser, bare for lige at nævne frontløberen blandt consumer diske...
#3 De har vel testet 10.000 diske samtidig, og konstateret at der gik 6 dage, 5 timer og 45 min imellem at en disk stod af?
#6 den er nok heller ik lavet til "generel lagring"... Ligesom en raptor ikke fås i store størrelser, bare for lige at nævne frontløberen blandt consumer diske...
#3 De har vel testet 10.000 diske samtidig, og konstateret at der gik 6 dage, 5 timer og 45 min imellem at en disk stod af?
Blah, roterende skiver .....foj
Giv mig solid state discs !!!
ps til jer der undre jer, jeg klarer mig med en 4GB flashdrive. Giver dig alt hvad du har brug for, hvor som helst pa hvilken som helst pc der kan boote pa usb
Giv mig solid state discs !!!
ps til jer der undre jer, jeg klarer mig med en 4GB flashdrive. Giver dig alt hvad du har brug for, hvor som helst pa hvilken som helst pc der kan boote pa usb
#10
Der er da ingen grund til at bruge hurtige diske til et database system, hvis databasen bliver nødt til at hive data fra disken, så går det allerede ALT for langsomt. Databaser skal ligge i hukommelse når de kører, der er ingen større fordel i at bruge hurtigere diske, især ikke hvis det går bare det mindste ud over pålideligheden, hvilket jeg kraftigt går udfra at 15000 RPM gør (i forhold til den samme teknologi ved f.eks. 10000).
Brug hellere de penge på 4 gb ekstra ram, det får du 100 gange så meget ud af i næsten ethvert setup. Det eneste sted i en serversetup hvor det her kunne have værdi er til system partition eller til storage (og det vil sandsynligvis fylde for meget og være for dyrt til storage).
Der er da ingen grund til at bruge hurtige diske til et database system, hvis databasen bliver nødt til at hive data fra disken, så går det allerede ALT for langsomt. Databaser skal ligge i hukommelse når de kører, der er ingen større fordel i at bruge hurtigere diske, især ikke hvis det går bare det mindste ud over pålideligheden, hvilket jeg kraftigt går udfra at 15000 RPM gør (i forhold til den samme teknologi ved f.eks. 10000).
Brug hellere de penge på 4 gb ekstra ram, det får du 100 gange så meget ud af i næsten ethvert setup. Det eneste sted i en serversetup hvor det her kunne have værdi er til system partition eller til storage (og det vil sandsynligvis fylde for meget og være for dyrt til storage).
#16
Databaser i hukommelsen er vel helt fint hvis man har en readonly
MS Access database.
Har man en stor database, så er der ikke plads til den i memory.
Og skriver man til databasen, så er databasens performance
bound by disk systemets performance.
15K diske har mig bekendt samme MTBF som 10K diske.
15K diske er standard i database servere.
Databaser i hukommelsen er vel helt fint hvis man har en readonly
MS Access database.
Har man en stor database, så er der ikke plads til den i memory.
Og skriver man til databasen, så er databasens performance
bound by disk systemets performance.
15K diske har mig bekendt samme MTBF som 10K diske.
15K diske er standard i database servere.
#17 du kan jo prøve... Mon ikke de har testet i en lang nok periode til at kunne sige noget om hvor ofte en disk af den type fejler? og evt. korrigeret tallet med den slidfaktor der vil opstår over årene.
#16 på mit arbejde har vi da sites hvor databasen fylder 60 GB, det er alligevel ikke sådan lige til at have i RAM...
#16 på mit arbejde har vi da sites hvor databasen fylder 60 GB, det er alligevel ikke sådan lige til at have i RAM...
#20 Selvom databasen fylder 60 GB er der sandsynligvist steder du ikke kommer ret ofte. Så hellere have alle nøgler og de allermest nødvendige data i hukommelse og en halvsløv disk end skulle swappe nøgler frem og tilbage selv på en meget hurtig disk!
Dog, - jeg kender naturligvis ikke jeres system. Det er jo forskelligt fra setup til setup.
Dog, - jeg kender naturligvis ikke jeres system. Det er jo forskelligt fra setup til setup.
Tror I alle skal kigge lidt forbi det private marked her :) Disse diske er primært til brug i appliance boxe og især Blade servere. De fylder nemlig dejlig lidt, og bruger mindre strøm. To faktorer som spiller de største roller i dag i moderne hosting selskaber.
Dermed er diskussionen herinde om at bruge dem til data drev også lidt irrelevant. Sådan noget klares med et SAN.
Men det er da ganske nydeligt at have en 15k disk array til system drevet, det kan KUN gavne mht. swap og lignende. Især fx. på en Terminal/Citrix server.
Dermed er diskussionen herinde om at bruge dem til data drev også lidt irrelevant. Sådan noget klares med et SAN.
Men det er da ganske nydeligt at have en 15k disk array til system drevet, det kan KUN gavne mht. swap og lignende. Især fx. på en Terminal/Citrix server.
#18
(off-topic, men...)
Synes ikke man kan sige der er nogen "standard" for dette?
10k diske er jo noget billigere og i DB sammenhæng handler det om antal spindler og controllercache (IKKE den på selve disken!). Nu kender jeg ikke de aktuelle priser, men sidst jeg tjeckede var 15k nææææsten dobbelt pris af en 10k (ved samme størrelse), så lad os antage at 30stk 15k diske koster det samme som 55stk 10k diske, så ville der nok være mere spark i det sidstnævnte setup. Dog bruger 10k og 15k diske næsten det samme i strøm (ca. 18watt/stk), så i sidste ende ville man nok vælge 15k løsningen i dag pga. TCO.
(off-topic, men...)
Synes ikke man kan sige der er nogen "standard" for dette?
10k diske er jo noget billigere og i DB sammenhæng handler det om antal spindler og controllercache (IKKE den på selve disken!). Nu kender jeg ikke de aktuelle priser, men sidst jeg tjeckede var 15k nææææsten dobbelt pris af en 10k (ved samme størrelse), så lad os antage at 30stk 15k diske koster det samme som 55stk 10k diske, så ville der nok være mere spark i det sidstnævnte setup. Dog bruger 10k og 15k diske næsten det samme i strøm (ca. 18watt/stk), så i sidste ende ville man nok vælge 15k løsningen i dag pga. TCO.
#16
(igen lidt off-topic)
Synes du modsiger dig selv lidt. Du vil have hele din DB i RAM og samtidig vil du have pålidelighed?? Håber ikke strømmen ryger fra din DB server nogensinde.....
Det er da rigtigt at en DB server skal have meget RAM, dét giver ligesom sig selv, men hvis den ikke kan committe changes lynhurtigt til disk, er al RAM i verden nytteløs. Dét der her kunne være en faktor var måske af benytte 10k diske og bruge de "sparede" pengen på en controller med en stor battery-backed-up Cache. Iøvrigt vil jeg give dig ret mht. brugen af 10k diske, men af andre årsager. Se evt. min post her ovenfor.
(igen lidt off-topic)
Synes du modsiger dig selv lidt. Du vil have hele din DB i RAM og samtidig vil du have pålidelighed?? Håber ikke strømmen ryger fra din DB server nogensinde.....
Det er da rigtigt at en DB server skal have meget RAM, dét giver ligesom sig selv, men hvis den ikke kan committe changes lynhurtigt til disk, er al RAM i verden nytteløs. Dét der her kunne være en faktor var måske af benytte 10k diske og bruge de "sparede" pengen på en controller med en stor battery-backed-up Cache. Iøvrigt vil jeg give dig ret mht. brugen af 10k diske, men af andre årsager. Se evt. min post her ovenfor.
#24
Jeg mener nu at det er standard at bruge 15K diske for database
servere (som skal performe godt).
Det er almindeligt kendt at write performance skalerer med
antal spindler, men det er altså samme slags spindler man
sammenligner.
Udover strøm forbruget er der to andre faktorer som taler
for 15K fremfor 10K:
* 2N stripede 10K diske har større transferrate end N stripede
15K diske, men også større access tid - og for databaser
er access tid ofte vigtigere end transferrate
* et disk system til at putte 2N diske i er ofte betydeligt
dyrere end et til at putte N diske i
Jeg mener nu at det er standard at bruge 15K diske for database
servere (som skal performe godt).
Det er almindeligt kendt at write performance skalerer med
antal spindler, men det er altså samme slags spindler man
sammenligner.
Udover strøm forbruget er der to andre faktorer som taler
for 15K fremfor 10K:
* 2N stripede 10K diske har større transferrate end N stripede
15K diske, men også større access tid - og for databaser
er access tid ofte vigtigere end transferrate
* et disk system til at putte 2N diske i er ofte betydeligt
dyrere end et til at putte N diske i
#25
What? Selvfølgelig skal dataen skrives til disken, men det gør du jo alligevel ikke i realtime. Selvfølgelig vedligeholder du en kopi af dataen på en disk, jeg ved ikke helt om du bevidst prøver at nedgøre mig eller hvad der sker, det troede jeg virkelig ikke jeg behøvede at nævne.
Når du designer en database, designer du den altid så den holder en del af databasen i hukommelsen, for ellers ville du få alt for mange disk søgninger, og den ville iøvrigt performe mere end almindeligt skidt. Derefter vil dataen så, lidt efter hvor langt et tabs-vindue du kan acceptere bliver skrevet til diskene. Men du får langt bedre performance hvis du holder en fuld (eller delvis) kopi i hukommelsen, eftersom det tager flere tusind gange så lang tid at arbejde på harddisken som i hukommelsen (jeg kan ikke huske den præcise ratio, den varierer også med typen).
Min pointe igennem hele det her er, at der er bedre måde at hente performance på end 15000 rpm diske, en af de bedre ville være et database cluster. For at være ærlig, der tror jeg ideen om at 15000 RPM skulle være en prismæssigt forsvarlig fordel, kommer fra manglende benchmarking og IT leverandører der hellere end gerne vil levere 'overlegne' løsninger.
What? Selvfølgelig skal dataen skrives til disken, men det gør du jo alligevel ikke i realtime. Selvfølgelig vedligeholder du en kopi af dataen på en disk, jeg ved ikke helt om du bevidst prøver at nedgøre mig eller hvad der sker, det troede jeg virkelig ikke jeg behøvede at nævne.
Når du designer en database, designer du den altid så den holder en del af databasen i hukommelsen, for ellers ville du få alt for mange disk søgninger, og den ville iøvrigt performe mere end almindeligt skidt. Derefter vil dataen så, lidt efter hvor langt et tabs-vindue du kan acceptere bliver skrevet til diskene. Men du får langt bedre performance hvis du holder en fuld (eller delvis) kopi i hukommelsen, eftersom det tager flere tusind gange så lang tid at arbejde på harddisken som i hukommelsen (jeg kan ikke huske den præcise ratio, den varierer også med typen).
Min pointe igennem hele det her er, at der er bedre måde at hente performance på end 15000 rpm diske, en af de bedre ville være et database cluster. For at være ærlig, der tror jeg ideen om at 15000 RPM skulle være en prismæssigt forsvarlig fordel, kommer fra manglende benchmarking og IT leverandører der hellere end gerne vil levere 'overlegne' løsninger.
#28
1) WriteBack cache og endda paa system niveau lyder ret
risikabelt for en database. WriteThrough cache er
da et absolut must paa system niveau og helt standard
ude paa controller niveau for databaser.
2) WriteBack kan bedre klare peaks, men performer jo ikke
bedre for sustained throughput.
1) WriteBack cache og endda paa system niveau lyder ret
risikabelt for en database. WriteThrough cache er
da et absolut must paa system niveau og helt standard
ude paa controller niveau for databaser.
2) WriteBack kan bedre klare peaks, men performer jo ikke
bedre for sustained throughput.
#29
Du siger det er risikabelt, og det har du for såvidt ret i, men faktum er at det bliver brugt mange steder. Spørgsmålet ligger i, hvor lang tids data er du villig til at tabe hvis systemet går ned? Hvis du er villig til at tabe 30 sekunder, så kan du sagtens få 20-30% ekstra performance på læsesiden. Om alle omstændigheder vil du med de fleste raid og disk opsætninger tabe et par sekunder, så du udryder heller ikke det problem ved at droppe WriteBack. Nu tror jeg iøvrigt ikke jeg sagde noget om at det skulle være WriteBack på system niveau, det var på applikations niveau jeg helst ville have det, når du siger på system niveau, mener du på kerne niveau (i modsætning til applikation), eller på system niveau (i modsætning til hardware)?
Du siger det er risikabelt, og det har du for såvidt ret i, men faktum er at det bliver brugt mange steder. Spørgsmålet ligger i, hvor lang tids data er du villig til at tabe hvis systemet går ned? Hvis du er villig til at tabe 30 sekunder, så kan du sagtens få 20-30% ekstra performance på læsesiden. Om alle omstændigheder vil du med de fleste raid og disk opsætninger tabe et par sekunder, så du udryder heller ikke det problem ved at droppe WriteBack. Nu tror jeg iøvrigt ikke jeg sagde noget om at det skulle være WriteBack på system niveau, det var på applikations niveau jeg helst ville have det, når du siger på system niveau, mener du på kerne niveau (i modsætning til applikation), eller på system niveau (i modsætning til hardware)?
#29
Jeg kan iøvrigt ikke være helt enig i, at du ikke får bedre performance i gennemsnit, desto større mængde data du giver en disk at skrive, desto mere søgning kan du undgå. Hvis vi snakkede om diske uden søgetid ville jeg være enig, men faktum er at en 15000 RPM disk stadig har en søgetid, en ret betydlig en, men hvis du brugte flash diske ville jeg give dig ret.
Jeg kan iøvrigt ikke være helt enig i, at du ikke får bedre performance i gennemsnit, desto større mængde data du giver en disk at skrive, desto mere søgning kan du undgå. Hvis vi snakkede om diske uden søgetid ville jeg være enig, men faktum er at en 15000 RPM disk stadig har en søgetid, en ret betydlig en, men hvis du brugte flash diske ville jeg give dig ret.
#30
Traditionel database filosofi siger at man er villig til at
acceptere nul data tab, hvis systemet gaar ned. Hvis en
transaktion er commited, saa bliver den ikke tabt.
Jeg kan heller ikke lige umiddelbart komme i tanke om
et mainstream database system, hvor loggen ikke bliver
skrevet ved commit. Det ses at data er bagefter, men
trabsaktions loggen er paa pladerne eller ihvertfald
i controllerens cache.
Traditionel database filosofi siger at man er villig til at
acceptere nul data tab, hvis systemet gaar ned. Hvis en
transaktion er commited, saa bliver den ikke tabt.
Jeg kan heller ikke lige umiddelbart komme i tanke om
et mainstream database system, hvor loggen ikke bliver
skrevet ved commit. Det ses at data er bagefter, men
trabsaktions loggen er paa pladerne eller ihvertfald
i controllerens cache.
#30
Nej. Hvorfor skulle man det ? Hvis data ikke er i styre systemets
cache, saa sker der ikke noget ved at styre systemet gaar ned.
Hvis det ene saet hardware gaar ned, saa skal det andet saet
faa skrevet data.
Om alle omstændigheder vil du med de fleste raid og disk opsætninger tabe et par sekunder
Nej. Hvorfor skulle man det ? Hvis data ikke er i styre systemets
cache, saa sker der ikke noget ved at styre systemet gaar ned.
Hvis det ene saet hardware gaar ned, saa skal det andet saet
faa skrevet data.
#30
Det sidste. Og hvilken type af memory det er betyder ikke noget
hvis systemet gaar ned.
Nu tror jeg iøvrigt ikke jeg sagde noget om at det skulle være WriteBack på system niveau, det var på applikations niveau jeg helst ville have det, når du siger på system niveau, mener du på kerne niveau (i modsætning til applikation), eller på system niveau (i modsætning til hardware)?
Det sidste. Og hvilken type af memory det er betyder ikke noget
hvis systemet gaar ned.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund