Hjemmeside » hvordan » Slik tweak din SSD i Ubuntu for bedre ytelse

    Slik tweak din SSD i Ubuntu for bedre ytelse

    Det er mange tips der ute for å tilpasse SSD i Linux og mange anekdotiske rapporter om hva som fungerer og hva som ikke gjør det. Vi kjørte våre egne referanser med noen spesifikke tweaks for å vise deg den virkelige forskjellen.

    benchmarks

    For å benchmark våre disk brukte vi Phoronix Test Suite. Det er gratis og har et lager for Ubuntu, slik at du ikke trenger å kompilere fra grunnen til å kjøre raske tester. Vi testet vårt system rett etter en ny installasjon av Ubuntu Natty 64-bit ved hjelp av standardparametrene for ext4 filsystemet.

    Systemets spesifikasjoner var som følger:

    • AMD Phenom II quad-core @ 3,2 GHz
    • MSI 760GM E51 hovedkort
    • 3,5 GB RAM
    • AMD Radeon 3000 integrert med 512 MB RAM
    • Ubuntu Natty

    Og selvfølgelig, SSD vi pleide å teste på var en 64 GB OCZ Onyx-stasjon ($ 117 på Amazon.com ved skrivingstidspunktet).

    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 greiene, lagde vi en kort liste over tweaks at Linux distros ikke har inkludert som standard for SSD. Tre av dem innebærer redigering av fstab-filen din, så kom tilbake 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 din. Hvis du ikke vet hva det er, eller vil du børste opp hvordan det fungerer, ta en titt på HTG Forklarer: Hva er Linux fstab og hvordan virker det??

    Eschewing Access Times

    Du kan bidra til å øke levetiden til SSD ved å redusere hvor mye operativsystemet skriver til disk. Hvis du trenger å vite når hver fil eller katalog ble sist tilgjengelig, kan du legge disse to alternativene til / etc / fstab-filen din:

    noatime, nodiratime

    Legg dem sammen med de andre alternativene, og sørg for at de er adskilt av komma og ikke mellomrom.

    Aktiverer TRIM

    Du kan aktivere TRIM for å hjelpe til med å administrere diskytelsen på lang sikt. Legg til følgende alternativ i fstab-filen din:

    forkaste

    Dette fungerer bra for ext4 filsystemer, selv på standard harddisker. Du må ha en kjerneversjon av minst 2.6.33 eller senere; du er dekket hvis du bruker Maverick eller Natty, eller har backports aktivert på Lucid. Selv om dette ikke forbedrer opprinnelig benchmarking, bør systemet gjøre det bedre på lang sikt, og det gjorde vår liste.

    tmpfs

    Systembufferen lagres i / tmp. Vi kan fortelle fstab å montere dette i RAM som et midlertidig filsystem, slik at systemet ditt berører harddisken mindre. Legg til følgende linje nederst i filen / etc / fstab i en ny linje:

    tmpfs / tmp tmpfs standard, noatime, modus = 1777 0 0

    Lagre fstab-filen din for å begå disse endringene.

    Bytte IO-planleggere

    Systemet skriver ikke alle endringer på disken umiddelbart, og flere forespørsler kommer i kø. Standard input-output scheduler - cfq - håndterer dette bra, men vi kan endre dette til en som fungerer bedre for maskinvaren vår.

    Først liste hvilke alternativer du har tilgjengelig med følgende kommando, erstatt "X" med brevet på rotstasjonen:

    katt / sys / blokk / sdX / kø / planlegger

    Min installasjon er på sda. Du bør se noen forskjellige alternativer.

    Hvis du har tidsfrist, bør du bruke det, da det gir deg en ekstra tweak lenger nedover linjen. Hvis ikke, bør du kunne bruke noop uten problemer. Vi må fortelle operativsystemet å bruke disse alternativene etter hvert oppstart, så vi må redigere den rc.local-filen.

    Vi bruker nano, siden vi er komfortable med kommandolinjen, men du kan bruke andre tekstredigeringsprogrammer du liker (gedit, vim, etc.).

    sudo nano /etc/rc.local

    Over "Avslutt 0" -linjen, legg til disse to linjene hvis du bruker tidsfrist:

    ekko deadline> / sys / block / sdX / kø / scheduler

    ekko 1> / sys / block / sdX / kø / iosched / fifo_batch

    Hvis du bruker noop, legg til denne linjen:

    ekko noop> / sys / block / sdX / kø / scheduler

    Igjen, erstatt "X" med riktig stasjonsbokstav for installasjonen. Se over alt for å sørge for at det ser bra ut.

    Deretter treffer du CTRL + O for å lagre, deretter CTRL + X for å slutte.

    Omstart

    For at alle disse endringene skal tre i kraft, må du starte om igjen. Etter det bør du være helt klar. Hvis noe går galt og du ikke kan starte, kan du systematisk fortryde hvert av trinnene ovenfor til du kan starte opp igjen. Du kan til og med bruke en LiveCD eller LiveUSB for å gjenopprette hvis du vil.

    FSTAB-endringene dine vil gjennomføre levetiden til installasjonen, selv om du ikke klarer å oppgradere, men din lokale endring må settes på nytt etter hver oppgradering (mellom versjoner).

    Benchmarking Results

    For å utføre referansene, kjørte vi diskpakken med tester. Toppbildet av hver test er før du justerer ext4-konfigurasjonen, og bunnbildet er etter tweaks og en omstart. Du vil se en kort forklaring på 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 disk. SSD-tweaksene her viser i en om lag 40% forbedring.

    IOzone simulerer filsystemytelse, i dette tilfellet ved å skrive en 8GB-fil. Igjen, en nesten 50% økning.

    Her leses en 8 GB-fil. Resultatene er nesten det samme som uten å justere ext4.

    AIO-Stress tester asynkront inngang og utgang, ved hjelp av en 2GB testfil og en 64KB rekordstørrelse. Her er det nesten 200% økning i ytelse sammenlignet med vanilje ext4!

    Små filoperasjoner

    En SQLite-database er opprettet, og PTS legger til 12 500 poster til den. SSD-tweaksene her reduserte faktisk ytelsen med ca 10%.

    Apache Benchmark testene tilfeldigvis leser av små filer. Det var omtrent 25% ytelsesgevinst etter optimalisering av SSD.

    PostMark simulerer 25.000 filtransaksjoner, 500 samtidig til enhver tid, med filstørrelser mellom 5 og 512KB. Dette simulerer web- og mail-servere ganske bra, og vi ser en 16% ytelsesøkning etter tweaking.

    FS-Mark ser på 1000 filer med en totalstørrelse på 1 MB, og måler hvor mange som kan skrives og leses på en forhåndsbestemt tid. Våre tweaks ser en økning, igjen, med mindre filstørrelser. Om en 45% økning med ext4 justeringer.

    Filsystemtilgang

    Dbench benchmarks test filsystemet kaller av klienter, som om hvordan Samba gjør ting. Her er vanilje ext4s ytelse kuttet med 75%, en stor tilbakegang i endringene vi har gjort.

    Du kan se at etter hvert som antall klienter går opp, øker ytelsesavviket.

    Med 48 klienter lukkede gapet noe mellom de to, men det er fortsatt et veldig tydelig resultatutfall ved våre tweaks.

    Med 128 klienter er ytelsen nesten den samme. Du kan anse at våre tweaks kanskje ikke er ideelle til hjemmebruk i denne typen operasjon, men vil gi sammenlignbar ytelse når antall kunder øker kraftig.

    Denne testen avhenger av kjernens AIO-tilgangsbibliotek. Vi har en 20% forbedring her.

    Her har vi en multi-threaded tilfeldig avlesning på 64 MB, og det er en 200% økning i ytelse her! Wow!

    Mens du skriver 64MB data med 32 tråder, har vi fortsatt en ytelse på 75%.

    Compile Bench simulerer effekten av alder på et filsystem som representert ved å manipulere kjernetrær (opprette, kompilere, lappe, etc.). Her kan du se en betydelig fordel gjennom den første opprettelsen av den simulerte kjernen, ca 40%.

    Disse referansene måler bare hvor lang tid det tar å pakke ut Linux-kjernen. Ikke for mye av en økning i ytelse her.

    Sammendrag

    Tilpasningene vi gjorde til Ubuntus ut-av-boks ext4-konfigurasjon, hadde en ganske stor innvirkning. De største prestasjonsvinduene var i rike av multi-threaded skriver og leser, liten fil leser, og stor sammenhengende fil leser og skriver. Faktisk var det eneste virkelige stedet vi så en suksess i enkle filsystem samtaler, noe som Samba-brukere bør passe på. Samlet ser det ut til å være en ganske solid økning i ytelse for ting som hosting websider og se / streame store videoer.

    Husk at dette var spesielt med Ubuntu Natty 64-bit. Hvis systemet ditt eller SSD er forskjellig, kan kjørelengdeet variere. Samlet skjønt, det virker som om fstab og IO scheduler justeringer vi gjorde, går langt til bedre ytelse, så det er sannsynligvis verdt å prøve på egen rigge.

    Har du egne referanser og ønsker å dele resultatene dine? Har du en annen tweak vi ikke vet om? Lyder ut i kommentarene!