Det er mange tips der ute for å tilpasse SSD-en din i Linux, og mange anekdotiske rapporter om hva som fungerer og hva som ikke fungerer. Vi kjørte våre egne referanser med noen få spesifikke justeringer for å vise deg den virkelige forskjellen.
Referanser
For å måle vår disk, brukte vi Phoronix Test Suite . Det er gratis og har et lager for Ubuntu, slik at du ikke trenger å kompilere fra bunnen av for å kjøre raske tester. Vi testet systemet vårt rett etter en ny installasjon av Ubuntu Natty 64-bit ved hjelp av standardparametrene for ext4-filsystemet.
Våre systemspesifikasjoner var som følger:
- AMD Phenom II firekjerner @ 3,2 GHz
- MSI 760GM E51 hovedkort
- 3,5 GB RAM
- AMD Radeon 3000 integrert m / 512 MB RAM
- Ubuntu Natty
Og selvfølgelig var SSD-en vi brukte til å teste på en 64 GB OCZ Onyx-stasjon ( $ 117 på Amazon.com i skrivende stund).
Fremtredende tweaks
Det er ganske mange endringer som folk anbefaler når de oppgraderer til en SSD. Etter å ha filtrert ut noen av de eldre tingene, laget vi en kort liste over justeringer som Linux-distroer ikke har tatt med som standard for SSD-er. Tre av dem involverer redigering av fstab-filen, så ta det igjen før du fortsetter med følgende kommando:
sudo cp / etc / fstab /etc/fstab.bak
Hvis noe går galt, kan du alltid slette den nye fstab-filen og erstatte den med en kopi av sikkerhetskopien. Hvis du ikke vet hva det er, eller hvis du vil pusse opp hvordan det fungerer, kan du ta en titt på det HTG forklarer: Hva er Linux fstab og hvordan fungerer det?
Eschewing tilgangstider
Du kan bidra til å øke SSD-ens levetid ved å redusere hvor mye operativsystemet skriver til disken. Hvis du trenger å vite når hver fil eller katalog ble sist åpnet, kan du legge til disse to alternativene i / etc / fstab-filen:
noatime, nodiratime
Legg til dem sammen med de andre alternativene, og sørg for at de alle er atskilt med komma og ingen mellomrom.
Aktiverer TRIM
Du kan aktivere TRIM for å administrere diskytelsen på lang sikt. Legg til følgende alternativ i fstab-filen:
kast
Dette fungerer bra for ext4-filsystemer, selv på standard harddisker. Du må ha en kjerneversjon på minst 2.6.33 eller nyere; du er dekket hvis du bruker Maverick eller Natty, eller har bakport aktivert på Lucid. Selv om dette ikke spesifikt forbedrer innledende benchmarking, bør det få systemet til å prestere bedre på lang sikt, og det gjorde listen vår.
Tmpfs
Systembufferen er lagret i / tmp. Vi kan fortelle fstab å montere dette i RAM-et som et midlertidig filsystem, slik at systemet ditt berører harddisken mindre. Legg til følgende linje nederst i / etc / fstab-filen i en ny linje:
tmpfs / tmp tmpfs standardinnstillinger, noatime, mode = 1777 0 0
Lagre fstab-filen for å utføre disse endringene.
Bytte IO-planleggere
Systemet ditt skriver ikke alle endringer på disken umiddelbart, og flere forespørsler blir satt i kø. Standard input-output scheduler - cfq - håndterer dette greit, men vi kan endre dette til en som fungerer bedre for maskinvaren vår.
Først bør du liste hvilke alternativer du har tilgjengelig med følgende kommando, og erstatte “X” med bokstaven til rotstasjonen:
cat / sys / block / sdX / kø / planlegger
Installasjonen min er på sda. Du bør se noen forskjellige alternativer.
Hvis du har frist, bør du bruke den, da den gir deg en ekstra justering lenger ned på linjen. Hvis ikke, bør du kunne bruke noop uten problemer. Vi må be OS om å bruke disse alternativene etter hver oppstart, så vi må redigere rc.local-filen.
Vi bruker nano, siden vi er komfortable med kommandolinjen, men du kan bruke hvilken som helst annen tekstredigerer du liker (gedit, vim, etc.).
Plutselig / Etc / rc.ぉ eller l
Over "exit 0" -linjen, legg til disse to linjene hvis du bruker fristen:
ekko frist> / sys / block / sdX / kø / planlegger
ekko 1> / sys / block / sdX / kø / iosched / fifo_batch
Hvis du bruker noop, kan du legge til denne linjen:
ekko noop> / sys / block / sdX / kø / planlegger
Nok en gang, erstatt “X” med riktig stasjonsbokstav for installasjonen. Se over alt for å sikre at det ser bra ut.
Trykk deretter CTRL + O for å lagre, deretter CTRL + X for å avslutte.
Omstart
For at alle disse endringene skal tre i kraft, må du starte på nytt. Etter det bør du være klar. Hvis noe går galt og du ikke kan starte, kan du systematisk angre hvert av trinnene ovenfor til du kan starte opp igjen. Du kan til og med bruke en LiveCD eller LiveUSB for å komme seg hvis du vil.
Fstab-endringene dine vil gjennomføre hele installasjonsperioden, til og med motstå oppgraderinger, men rc.local-endringen din må reinstalleres etter hver oppgradering (mellom versjoner).
Referanseresultater
For å utføre referansene kjørte vi disksuiten med tester. Det øverste bildet av hver test er før du justerer ext4-konfigurasjonen, og det nederste bildet er etter justeringene og en omstart. Du får se en kort forklaring av hva testen måler, samt en tolkning av resultatene.
Store filoperasjoner
Denne testen komprimerer en 2 GB-fil med tilfeldige data og skriver den til disken. SSD-tilpasningene her viser omtrent 40% forbedring.
IOzone simulerer filsystemytelsen, i dette tilfellet ved å skrive en 8 GB-fil. Igjen, en økning på nesten 50%.
Her leses en 8 GB-fil. Resultatene er nesten de samme som uten å justere ext4.
AIO-Stress tester inndata og utdata asynkront ved hjelp av en 2 GB testfil og en 64 KB rekordstørrelse. Her er det nesten 200% økning i ytelsen sammenlignet med vanilje ext4!
Små filoperasjoner
En SQLite-database opprettes og PTS legger til 12 500 poster i den. SSD-tilpasningene her reduserte faktisk ytelsen med omtrent 10%.
Apache Benchmark tester tilfeldige avlesninger av små filer. Det var omtrent 25% ytelsesgevinst etter optimalisering av SSD-en.
PostMark simulerer 25 000 filtransaksjoner, 500 samtidig til enhver tid, med filstørrelser mellom 5 og 512 KB. Dette simulerer nett- og e-postservere ganske bra, og vi ser en ytelsesøkning på 16% etter finjustering.
FS-Mark ser på 1000 filer med en total størrelse på 1 MB, og måler hvor mange som kan skrives fullstendig og leses på forhåndsbestemt tid. Våre tweaks ser en økning igjen med mindre filstørrelser. Omtrent 45% økning med ext4-justeringer.
Tilgang til filsystem
Dbench-referansetestfilsystemets anrop fra klienter, som om hvordan Samba gjør ting. Her blir ytelsen til vanilla ext4 redusert med 75%, et stort tilbakeslag i endringene vi gjorde.
Du kan se at når antall kunder øker, øker avviket mellom ytelse.
Med 48 klienter lukket gapet noe mellom de to, men det er fortsatt et veldig tydelig ytelsestap av våre justeringer.
Med 128 klienter er ytelsen nesten den samme. Du kan resonnere at våre justeringer kanskje ikke er ideelle for hjemmebruk i denne typen operasjoner, men vil gi sammenlignbar ytelse når antall kunder økes kraftig.
Denne testen avhenger av kjernens AIO-tilgangsbibliotek. vi har 20% forbedring her.
Her har vi en flertrådet tilfeldig lesing på 64 MB, og det er en økning på 200% i ytelsen her! Wow!
Mens vi skriver 64 MB data med 32 tråder, har vi fortsatt 75% økning i ytelse.
Compile Bench simulerer alderseffekten på et filsystem som representert ved å manipulere kjernetrær (lage, kompilere, lappe osv.). Her kan du se en betydelig fordel gjennom den første opprettelsen av den simulerte kjernen, omtrent 40%.
Disse målene måler ganske enkelt hvor lang tid det tar å trekke ut Linux-kjernen. Ikke for mye av en økning i ytelsen her.
Sammendrag
Justeringene vi gjorde i Ubuntus out-of-the-box ext4-konfigurasjon hadde ganske stor innvirkning. Den største ytelsesgevinsten var i områdene av skriving og lesing med flere tråder, lesing av små filer og store sammenhengende filer som leses og skrives. Faktisk var det eneste virkelige stedet vi så et treff i ytelsen i enkle filsystemanrop, noe Samba-brukere burde passe på. Totalt sett ser det ut til å være en ganske solid økning i ytelse for ting som å hoste websider og se / streame store videoer.
Husk at dette var spesielt med Ubuntu Natty 64-bit. Hvis systemet eller SSD-en din er annerledes, kan kjørelengden din variere. Alt i alt virker det som om fstab- og IO-planleggerjusteringene vi gjorde, går langt for bedre ytelse, så det er sannsynligvis verdt å prøve på din egen rigg.
Har du dine egne referanser og vil dele resultatene dine? Har du en ny justering vi ikke vet om? Hør ut i kommentarene!
