Slik tweak din SSD i Ubuntu for bedre ytelse

2024 Forfatter: Geoffrey Carr | [email protected]. Sist endret: 2024-01-31 12:50

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 skrivingstid).

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-er. 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 fungerer 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 oppnådd, kan du legge disse to alternativene til din / etc / fstab-fil:


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 å bidra til å administrere diskytelsen på lang sikt. Legg til følgende alternativ i fstab-filen din:


discard

Dette fungerer bra for ext4 filsystemer, selv på standard harddisker. Du må ha en kjerneversjon på 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 defaults,noatime,mode=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:


cat /sys/block/sdX/queue/scheduler

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:


echo deadline > /sys/block/sdX/queue/scheduler
echo 1 > /sys/block/sdX/queue/iosched/fifo_batch

Hvis du bruker noop, legg til denne linjen:


echo noop > /sys/block/sdX/queue/scheduler

Igjen, erstatt "X" med riktig stasjonsbokstav for installasjonen. Se over alt for å sikre 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 LiveCD eller LiveUSB til å gjenopprette hvis du vil.

FSTAB-endringene dine vil gjennomføre installasjonsperioden, 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 til hver test er før du tilpasser 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 filsystemet ytelse, i dette tilfellet ved å skrive en 8GB fil. Igjen, en nesten 50% økning.

Her leses en 8GB-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 om lag 10%.

Apache Benchmark tester 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 total stø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 ytelsestap 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 tilsvarende ytelse når antall klienter økes 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 75% økning i ytelsen.

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 opprinnelige opprettelsen av den simulerte kjernen, om lag 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 har gjort til Ubuntu er ute av boks ext4-konfigurasjonen, har 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 Samba-brukere burde 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 ditt variere. Samlet skjønt, det virker som om fstab og IO scheduler justeringer vi gjorde, går langt til bedre ytelse, så det er nok verdt å prøve på din egen rigg.

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