Sådan tweak din SSD i Ubuntu for bedre ydeevne

Der er masser af tips derude til tweaking din SSD i Linux og masser af anekdotiske rapporter om, hvad der virker, og hvad der ikke gør. Vi løb vores egne benchmarks med et par specifikke tweaks for at vise dig den virkelige forskel.

benchmarks

For at benchmark vores disk brugte vi Phoronix Test Suite. Det er gratis og har et opbevaringssted til Ubuntu, så du behøver ikke at kompilere fra bunden til at køre hurtige tests. Vi testede vores system lige efter en frisk installation af Ubuntu Natty 64-bit ved hjælp af standardparametrene for ext4 filsystemet.

Vores systemspecifikationer var som følger:

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

Og selvfølgelig var SSD'en, vi plejede at teste på, et 64 GB OCZ Onyx-drev ($ 117 på Amazon.com på tidspunktet for skrivning).

Fremtrædende Tweaks

Der er et par ændringer, som folk anbefaler, når de opgraderer til en SSD. Efter at have filtreret nogle af de ældre ting ud, lavede vi en kort liste over tweaks, at Linux distros ikke har medtaget som standard for SSD'er. Tre af dem indebærer redigering af din fstab-fil, så back den op, før du fortsætter med følgende kommando:

sudo cp / etc / fstab /etc/fstab.bak

Hvis noget går galt, kan du altid slette den nye fstab-fil og erstatte den med en kopi af din backup. Hvis du ikke ved hvad det er, eller du vil børste op om, hvordan det virker, skal du kigge på HTG Forklarer: Hvad er Linux fstab og hvordan virker det??

Eschewing Access Times

Du kan bidrage til at øge levetiden for din SSD ved at reducere, hvor meget operativsystemet skriver til disk. Hvis du har brug for at vide, hvornår hver fil eller mappe sidst blev åbnet, kan du tilføje disse to muligheder til din / etc / fstab-fil:

noatime, nodiratime

Tilføj dem sammen med de andre muligheder, og sørg for, at de alle adskilles af kommaer og intet mellemrum.

Aktiverer TRIM

Du kan aktivere TRIM til at hjælpe med at styre diskens ydeevne på lang sigt. Tilføj følgende mulighed til din fstab-fil:

kassere

Dette fungerer godt for ext4 filsystemer, selv på standard harddiske. Du skal have en kernelversion på mindst 2.6.33 eller senere; du er dækket, hvis du bruger Maverick eller Natty, eller har backports aktiveret på Lucid. Selvom dette ikke forbedrer den oprindelige benchmarking specifikt, bør det gøre systemet bedre på lang sigt, og det gjorde vores liste.

tmpfs

Systemets cache er gemt i / tmp. Vi kan fortælle fstab at montere dette i RAM som et midlertidigt filsystem, så dit system vil røre harddisken mindre. Tilføj følgende linje til bunden af ​​din / etc / fstab-fil i en ny linje:

tmpfs / tmp tmpfs standarder, noatime, mode = 1777 0 0

Gem din fstab-fil for at begå disse ændringer.

Skifte IO Scheduler

Dit system skriver ikke alle ændringer til disken med det samme, og flere forespørgsler kommer i kø. Standard input-output scheduler - cfq - håndterer dette okay, men vi kan ændre dette til en, der fungerer bedre for vores hardware.

Først skal du liste hvilke muligheder du har til rådighed med følgende kommando, og erstatte "X" med brevet på dit rootdrev:

cat / sys / block / sdX / kø / scheduler

Min installation er på sda. Du bør se et par forskellige muligheder.

Hvis du har deadline, skal du bruge det, da det giver dig en ekstra tweak længere nede på linjen. Hvis ikke, skal du kunne bruge noop uden problemer. Vi skal fortælle OS at bruge disse muligheder efter hver boot, så vi skal redigere den rc.local-fil.

Vi bruger nano, da vi er fortrolige med kommandolinjen, men du kan bruge enhver anden teksteditor du kan lide (gedit, vim, etc.).

sudo nano /etc/rc.local

Over linjen "Afslut 0", tilføj disse to linjer, hvis du bruger deadline:

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

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

Hvis du bruger noop, tilføj denne linje:

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

Endnu en gang skal du erstatte "X" med det korrekte drevbogstav til din installation. Se over alt for at sikre, at det ser godt ud.

Klik derefter på CTRL + O for at gemme, så CTRL + X for at afslutte.

Genstart

For at alle disse ændringer skal træde i kraft, skal du genstarte. Derefter skal du være helt indstillet. Hvis noget går galt, og du ikke kan starte, kan du systematisk fortryde hvert af ovenstående trin, indtil du kan starte igen. Du kan endda bruge en LiveCD eller LiveUSB til at gendanne, hvis du vil.

Dine fstab-ændringer vil gennemføre hele installationens levetid, selv om der ikke opnås opgraderinger, men din rc.local-ændring skal geninstalleres efter hver opgradering (mellem versioner).

Benchmarking Resultater

For at udføre benchmarksne kørte vi diskpakken af ​​tests. Det øverste billede af hver test er før tweaking ext4-konfigurationen, og bundbilledet er efter tweaks og en genstart. Du vil se en kort forklaring på, hvad testen måler samt en fortolkning af resultaterne.

Store filoperationer

Denne test komprimerer en 2 GB-fil med tilfældige data og skriver den til disk. SSD-tweaks her viser i en forbedring på ca. 40%.

IOzone simulerer filsystem ydeevne, i dette tilfælde ved at skrive en 8GB fil. Igen, en næsten 50% stigning.

Her læses en 8GB-fil. Resultaterne er næsten de samme som uden at justere ext4.

AIO-Stress tester asynkront input og output ved hjælp af en 2GB testfil og en 64KB rekordstørrelse. Her er der næsten 200% forøgelse i forhold til vanille ext4!

Små filoperationer

En SQLite-database oprettes, og PTS tilføjer 12.500 poster til den. SSD-tweaks her reducerede faktisk ydeevnen med ca. 10%.

Apache Benchmark tests tilfældigt læser små filer. Der var omkring en præstation på 25% efter optimering af vores SSD.

PostMark simulerer 25.000 filtransaktioner, 500 samtidig til enhver tid, med filstørrelser mellem 5 og 512KB. Dette simulerer web- og mail-servere ret godt, og vi ser en 16% præstationsforøgelse efter tweaking.

FS-Mark ser på 1000 filer med en samlet størrelse på 1 MB, og måler, hvor mange der kan skrives fuldstændigt og læses i en forudbestemt tid. Vores tweaks ser en stigning igen med mindre filstørrelser. Om en 45% stigning med ext4 justeringer.

Filsystemadgang

Dbench benchmarks test filsystemet kalder af klienter, sådan som om Samba gør ting. Her reduceres vanilje ext4's præstation med 75%, en stor tilbagegang i de ændringer, vi har foretaget.

Du kan se, at når antallet af klienter går op, stiger præstationsafvigelsen.

Med 48 klienter lukkede hullet noget mellem de to, men der er stadig et meget tydeligt resultat tab af vores tweaks.

Med 128 klienter er forestillingen næsten den samme. Du kan begrunde, at vores tweaks måske ikke er ideelle til hjemmebrug i denne form for operation, men vil give sammenlignelig ydeevne, når antallet af kunder er stærkt forøget.

Denne test afhænger af kernens AIO-adgangsbibliotek. vi har en 20% forbedring her.

Her har vi en multi-threaded tilfældig læsning på 64 MB, og der er en 200% stigning i ydeevne her! Wow!

Mens der skrives 64 MB data med 32 tråde, har vi stadig en præstation på 75%.

Compile Bench simulerer virkningen af ​​alder på et filsystem som repræsenteret ved at manipulere kernetræer (oprettelse, kompilering, patching osv.). Her kan du se en betydelig fordel ved den oprindelige oprettelse af den simulerede kerne, ca. 40%.

Disse benchmarks måler kun, hvor lang tid det tager at udpakke Linux-kernen. Ikke for meget af en stigning i præstationen her.

Resumé

De tilpasninger, vi lavede til Ubuntu's out-of-the-box ext4-konfiguration, havde en ret indflydelse. De største præstationsgevinster var i rigdommene af multi-threaded skriver og læser, små filer læser, og stor sammenhængende fil læser og skriver. Faktisk var det eneste virkelige sted, vi oplevede et resultat i simple filsystemopkald, noget, som Samba-brugere skal passe på. Samlet set synes det at være en temmelig solid stigning i ydeevne for ting som hosting websider og se / streame store videoer.

Husk på, at dette var specifikt med Ubuntu Natty 64-bit. Hvis dit system eller SSD er anderledes, kan din kilometertal variere. Samlet set ser det ud til, at de fstab og IO scheduler justeringer, vi lavede, går langt til bedre ydeevne, så det er nok et forsøg på din egen rig.

Har du egne benchmarks og ønsker at dele dine resultater? Har en anden tweak vi ikke ved om? Lyde ud i kommentarerne!