mboost-dp1
Western Digital Corp.
Det giver vel også et performanceløft i form at færre læsninger/skrivninger til disk?
Bare skod med et system som et af vores der lægger små logfiler på 39 bytes. Faktisk størrelse 68MB, størrelse på disk 2GB
Bare skod med et system som et af vores der lægger små logfiler på 39 bytes. Faktisk størrelse 68MB, størrelse på disk 2GB
Jeg synes nyheden lyder lidt mærkelig.
Der det ikke bare understøttelsen på sektorer der er under 4KB der bliver fjernet på dem?
Jeg har i hvert flad kørt med 64KB clusterstørrelse på alle mine harddiske, undtagen systemdrev, som netop kører med 4KB clusterstørrelse.
Der det ikke bare understøttelsen på sektorer der er under 4KB der bliver fjernet på dem?
Jeg har i hvert flad kørt med 64KB clusterstørrelse på alle mine harddiske, undtagen systemdrev, som netop kører med 4KB clusterstørrelse.
Nyheden er lidt misvisende på det her punkt. Som sådan har sektorstørrelsen intet med fil-størrelse at gøre. Filer og mapper findes ikke i harddiskens verden, det er noget operativsystemet håndterer. Det vil sige at man kun kan skrive i klumper af 4 KB, men det betyder ikke at man ikke kan lægge 100 filer á 39 bytes på de 4 KB, OS'et skal bare i princippet skrive alle 4 KB og dermed alle 100 filers data-indhold på én gang. Det er ikke nødvendigvis et performanceproblem...FritzFarlig (1) skrev:Det giver vel også et performanceløft i form at færre læsninger/skrivninger til disk?
Bare skod med et system som et af vores der lægger små logfiler på 39 bytes. Faktisk størrelse 68MB, størrelse på disk 2GB
Clusterstørrelse har intet som helst med sektorstørrelse at gøre. Clusterstørrelse er et begreb man arbejder med i fil-systemer. En stor clusterstørrelse har de konsekvenser som #1 også antyder.Jakob Jakobsen (3) skrev:Jeg synes nyheden lyder lidt mærkelig.
Der det ikke bare understøttelsen på sektorer der er under 4KB der bliver fjernet på dem?
Jeg har i hvert flad kørt med 64KB clusterstørrelse på alle mine harddiske, undtagen systemdrev, som netop kører med 4KB clusterstørrelse.
mathiass (4) skrev:Nyheden er lidt misvisende på det her punkt. Som sådan har sektorstørrelsen intet med fil-størrelse at gøre. Filer og mapper findes ikke i harddiskens verden, det er noget operativsystemet håndterer. Det vil sige at man kun kan skrive i klumper af 4 KB, men det betyder ikke at man ikke kan lægge 100 filer á 39 bytes på de 4 KB, OS'et skal bare i princippet skrive alle 4 KB og dermed alle 100 filers data-indhold på én gang. Det er ikke nødvendigvis et performanceproblem...
OK, jeg gik bare ud fra at i dag kan du i fx windows ikke lave en allokeringsstørrelse på mindre end 512byte. Jeg gik ud fra årsagen til dette er sektorstørrelsen på harddisken og man derfor i det nye setup ikke kan formatere med en allokeringsstørrelse på mindre end de 4KB. Og at de større sektorer på harddisken vil mindske IO, da du kan læse/skrive flere data i en enkelt IO operation = mindre overhead
FritzFarlig (1) skrev:Det giver vel også et performanceløft i form at færre læsninger/skrivninger til disk?
Bare skod med et system som et af vores der lægger små logfiler på 39 bytes. Faktisk størrelse 68MB, størrelse på disk 2GB
Kan du ikke fikse det ved at komprimere mappen, som logfilerne ligger i? Således bliver filerne jo betragtet som en enkelt fil og du fjerner de 4096-39 bytes overhead på bekostning af en smule performance. Det burde forholdsvis nemt kunne implementeres til at arbejde sammen med det system der logger, hvis det ikke kan klares i OS'et.
I teorien vil kapaciteten og hastigheden vil stige med 7-11%. Men HD-producenterne næppe vil begynde at sælge 1.1TB diske. Så vis man købe en sådan en ny disk, vil den enten være en lille smule hurtigere, eller meget langsommer. Alt efter hvilket OS man køre.
Den forbedret ECC ser dog interesant ud.
Den forbedret ECC ser dog interesant ud.
Logifire (8) skrev:Hvad er clusterstørrelse?
Det er hvor store clusterne der bruges i filsystemet.
Hvis det du ville vide var hvad en cluster er, så se: http://en.wikipedia.org/wiki/Data_cluster
NeedNoName (6) skrev:
Kan du ikke fikse det ved at komprimere mappen, som logfilerne ligger i? Således bliver filerne jo betragtet som en enkelt fil og du fjerner de 4096-39 bytes overhead på bekostning af en smule performance. Det burde forholdsvis nemt kunne implementeres til at arbejde sammen med det system der logger, hvis det ikke kan klares i OS'et.
Filerne lagres kun i komprimeret tilstand. De bliver dekomprimeret ved læsning og det koster i performance. Men du tænker måske på en anden løsning? for det jeg omtaler kræver ikke noget specielt i forhold til de programmer det måtte tilgå en komprimeret fil.
#10: Jamen hvis filerne lagres i komprimeret tilstand, så burde du da heller ikke have det voldsomme overhead du snakker om...?
#11: Ja, jeg skiftede vidst lidt emne. Det har du ret i, men det giver bare et ryk nedad i performance som man lige skal overveje i et driftsmiljø. I mit konkrete tilfælde vil performance ikke være noget problem, men det er så små mængder data, det ikke er værd at overveje at komprimere :).
#12,
Pointen i at komprimere dem, er jo at pakke dem sammen i én fil.
e.g. i laver 10 filer af 39 bytes per dag
lageret enkeeltvis, tager de 40 kb (10 x 4 kb)
pakket sammen i en fil, fylder de 4 kb (10 x 39 bytes + overhead < 4 kb)
evt. pak alle logfiler sammen baseret på uge eller måned, eller bare alle logfiler ældre end x dage ned i en fil... så spare i meget plads.
Pointen i at komprimere dem, er jo at pakke dem sammen i én fil.
e.g. i laver 10 filer af 39 bytes per dag
lageret enkeeltvis, tager de 40 kb (10 x 4 kb)
pakket sammen i en fil, fylder de 4 kb (10 x 39 bytes + overhead < 4 kb)
evt. pak alle logfiler sammen baseret på uge eller måned, eller bare alle logfiler ældre end x dage ned i en fil... så spare i meget plads.
FritzFarlig (12) skrev:#11: Ja, jeg skiftede vidst lidt emne. Det har du ret i, men det giver bare et ryk nedad i performance som man lige skal overveje i et driftsmiljø. I mit konkrete tilfælde vil performance ikke være noget problem, men det er så små mængder data, det ikke er værd at overveje at komprimere :).
Ja, det er jo et spørgsmål om performance kontra diskplads og HD'er er så billige, at det nok aldrig ville blive et problem i større skala når der er en større økonomi bag. ;)Saxov (13) skrev:#12,
Pointen i at komprimere dem, er jo at pakke dem sammen i én fil.
e.g. i laver 10 filer af 39 bytes per dag
lageret enkeeltvis, tager de 40 kb (10 x 4 kb)
pakket sammen i en fil, fylder de 4 kb (10 x 39 bytes + overhead < 4 kb)
evt. pak alle logfiler sammen baseret på uge eller måned, eller bare alle logfiler ældre end x dage ned i en fil... så spare i meget plads.
FritzFarlig (1) skrev:Det giver vel også et performanceløft i form at færre læsninger/skrivninger til disk?
Bare skod med et system som et af vores der lægger små logfiler på 39 bytes. Faktisk størrelse 68MB, størrelse på disk 2GB
Har du overvejet at logge til en database i stedet for?
Det burde løse det problem, og kunne formentligt give et performance-boost oveni.
#16 Har du overvejet at man i den virkelige verden som regl ikke selv har skrevet det software ens arbejdsplads bruger, ej heller har man adgang til kildekoden eller en chef der ville gide betale dig 10 timers løn for at spare 2GB diskplads.
Angelenglen (16) skrev:Har du overvejet at logge til en database i stedet for?
Det burde løse det problem, og kunne formentligt give et performance-boost oveni.
IMO så er logging til databaser sjældent et skridt fremad.
Det giver yderligere et niveau af kompleksitet / funktionalitet, der skal være i luften, før du kan skrive din log.
Dvs. i en fejl situation er der større chance for, at du ikke har logget de hændelser, der førte frem til en fejl.
Jeg tror heller ikke du kan logge hurtigere til en db end du kan appende en linje til en fil. Der skal trods alt ikke søges i indexes eller andet, blot indsættes i slutningen af filen.
#21: my new best friend. En af de tidligere versioner af programmet krævede man skulle være logget ind på "console" før det kørte. Det gør det principielt stadigvæk men har pakket det ind i alwaysup.
Barnabas (20) skrev:IMO så er logging til databaser sjældent et skridt fremad.
Det giver yderligere et niveau af kompleksitet / funktionalitet, der skal være i luften, før du kan skrive din log.
Dvs. i en fejl situation er der større chance for, at du ikke har logget de hændelser, der førte frem til en fejl.
Jeg tror heller ikke du kan logge hurtigere til en db end du kan appende en linje til en fil. Der skal trods alt ikke søges i indexes eller andet, blot indsættes i slutningen af filen.
IMO er logning til databaser et skridt fremad.
Det går hurtigere, og det er lettere at finde informationen igen når der er brug for den.
Det er lettere at automatisere overvågning af indholdet i loggen, så der eksempelvis kan sendes mail-alarm ud hvis der logges fejl eller lignende.
Det kan godt være det stiller større krav til vedligeholdelse, men IMO er det klart at foretrække, såfremt det er en mulighed.
FritzFarlig (19) skrev:#16: Som #18 så rigtigt bemærker er man ikke altid selv herre over den software man har i et firma :). Så det bestemmer jeg ikke selv i dette tilfælde.
Med de få detaljer du stillede til rådighed, var det ikke en mulighed for mig at vide det.
Det var bare et forslag, det kunne jo være det kunne hjælpe.
På mit arbejde har vi også et program der ikke kan andet end at lave en ny logfil hver time, hvilket resulterer i en masse små logfiler.
Her "løste" vi problemer ved at køre et script hver weekend, der samler ugens logfiler i et samlet komprimeret arkiv for hver uge (og sletter ukomprimerede filer efter sig).
Det er dog kun en løsning fordi vi så sjældent har brug for at kigge i de logfiler, faktisk har vi aldrig haft brug for det, men man er jo nødt til at gemme dem alligevel, for man ved jo aldrig...
#14
Ifølge artiklen emulerer WD disken 512 byte sektorer, så den vil virke med ældre systemer. Hvis du kigger nærmere på artiklen kan du også se at HD producenterne godt kunne tænke sig at se Win XP og ældre Windows versioner dø ASAP, da de opfører sig meget dårligt med 4kB sektorer. Win XP har en crappy alignment på partitioner den opretter, så WD har både en jumper workaround og en utility der kan realigne partitioner på disken hvis den er så uheldig at være inficeret med Win XP eller ældre.
Ifølge artiklen emulerer WD disken 512 byte sektorer, så den vil virke med ældre systemer. Hvis du kigger nærmere på artiklen kan du også se at HD producenterne godt kunne tænke sig at se Win XP og ældre Windows versioner dø ASAP, da de opfører sig meget dårligt med 4kB sektorer. Win XP har en crappy alignment på partitioner den opretter, så WD har både en jumper workaround og en utility der kan realigne partitioner på disken hvis den er så uheldig at være inficeret med Win XP eller ældre.
Angelenglen (24) skrev:Det går hurtigere, og det er lettere at finde informationen igen når der er brug for den.
Det er lettere at automatisere overvågning af indholdet i loggen, så der eksempelvis kan sendes mail-alarm ud hvis der logges fejl eller lignende.
Det kan godt være det stiller større krav til vedligeholdelse, men IMO er det klart at foretrække, såfremt det er en mulighed.
Hvad præcis mener du med "hurtigere" ? Det er ikke hurtigere at indsætte en række i en database end det er at appende til en fil. Jeg bør måske lige nævne at jeg har en baggrund som oracle udvikler / dba.
Sandsynligvis skal der flere skrivninger til, da du typisk skal opdatere/indsætte i tabel + et eller flere indexes skal modificeres.
Det er nøjagtig lige så let at overvåge en fil automatisk og sende et mail ud. Det kan alle moderne overvågnings systemer.
Hvor logger din applikation, hvis det er forbindelsen fra appserveren til dbserveren, eller dbserveren selv der dør?
Du skal under alle omstændigheder have noget alternativt i luften.
#24 Bare surt hvis man har Logfilerne fra databasen til at ligge i databasen :) Spøg til side!
Nææh.. Syslog-ng og logrotate er lige min kop the.. Der kan du endda forwarde logs til flere servere, samt modtage logfiler fra routere/switches.
Satte et system op hos den ISP jeg arbejdede hos der sørgede for at gemme logfilerne fra alle switches/routers i et bibliotek med mappestruktur for dato/time, og så ellers pakke månedens bibliotek ned i en tar.gz :)
Nææh.. Syslog-ng og logrotate er lige min kop the.. Der kan du endda forwarde logs til flere servere, samt modtage logfiler fra routere/switches.
Satte et system op hos den ISP jeg arbejdede hos der sørgede for at gemme logfilerne fra alle switches/routers i et bibliotek med mappestruktur for dato/time, og så ellers pakke månedens bibliotek ned i en tar.gz :)
#24
Helt enig, Syslog er cool og kan både remote logging, file rolling og pakning af de gamle. Som man så stadig kan søge i med zcat og zgrep. Det er cool.
Og eks. oracle har også sine logfiler liggende udenfor databasen. Både dem til alm. beskeder og til archive loggen. Hvis de lå i databasen, så ville man have et problem, hvis den datafil de var skrevet til var korrupt til en grad den ikke kunne bruges.
Så ville man mangle alt fra sidste incremental/full backup op til crash tidspunktet. Surt show.
Helt enig, Syslog er cool og kan både remote logging, file rolling og pakning af de gamle. Som man så stadig kan søge i med zcat og zgrep. Det er cool.
thethufir (29) skrev:Bare surt hvis man har Logfilerne fra databasen til at ligge i databasen :
Og eks. oracle har også sine logfiler liggende udenfor databasen. Både dem til alm. beskeder og til archive loggen. Hvis de lå i databasen, så ville man have et problem, hvis den datafil de var skrevet til var korrupt til en grad den ikke kunne bruges.
Så ville man mangle alt fra sidste incremental/full backup op til crash tidspunktet. Surt show.
Lav et filbaseret-filsystem, det er ikke rocket science.
nu skal jeg se 0m jeg kan spare din arbejdsgiver for 10 timers løn...
noget ala (hvis du sidder med bsd)
dd if=/dev/zero of=/home/filsystem bs=1M count=så meget som du skal bruge
mdconfig -at vnode -f /home/filsystem -u 0/1/2/wherever
newfs -b 39/68 md0/1/2/wherever
mount md0/1/2/whever /mnt/der hvor du vil have din logfiler
Upti-Wupti, done.
nu skal jeg se 0m jeg kan spare din arbejdsgiver for 10 timers løn...
noget ala (hvis du sidder med bsd)
dd if=/dev/zero of=/home/filsystem bs=1M count=så meget som du skal bruge
mdconfig -at vnode -f /home/filsystem -u 0/1/2/wherever
newfs -b 39/68 md0/1/2/wherever
mount md0/1/2/whever /mnt/der hvor du vil have din logfiler
Upti-Wupti, done.
FritzFarlig (1) skrev:
Bare skod med et system som et af vores der lægger små logfiler på 39 bytes. Faktisk størrelse 68MB, størrelse på disk 2GB
Then use a file system that supports block suballocation, such as reiserfs or btrfs.
#36
Anandtech siger "Any day now", men det ser ikke ud til at være det store man vinder på de her 1. generations drev. Pga. Win XP bliver alle de her drev nødt til at holde fast i 512 byte sektor størrelse mod OS, og så mappe internt. De første drev der kommer er WD Green hvor buffer er vokset til 64MB, så hvis du alligevel skulle have en WD Green og mener en 32->64MB buffer increase er værd at vente på, så vent, ellers ikke.
Anandtech siger "Any day now", men det ser ikke ud til at være det store man vinder på de her 1. generations drev. Pga. Win XP bliver alle de her drev nødt til at holde fast i 512 byte sektor størrelse mod OS, og så mappe internt. De første drev der kommer er WD Green hvor buffer er vokset til 64MB, så hvis du alligevel skulle have en WD Green og mener en 32->64MB buffer increase er værd at vente på, så vent, ellers ikke.
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