Hur tweak din SSD i Ubuntu för bättre prestanda

Det finns massor av tips där ute för att tweak din SSD i Linux och många anekdotiska rapporter om vad som fungerar och vad som inte gör det. Vi sprang våra egna riktmärken med några specifika tweaks för att visa dig den verkliga skillnaden.

benchmarks

För att benchmarka vår disk, använde vi Phoronix Test Suite. Det är gratis och har ett repository för Ubuntu så att du inte behöver kompilera från början för att köra snabbtester. Vi testade vårt system strax efter en ny installation av Ubuntu Natty 64-bit med standardparametrarna för ext4-filsystemet.

Våra systemspecifikationer var följande:

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

Och, självklart, SSD som vi brukade testa på var en 64 GB OCZ Onyx-enhet ($ 117 på Amazon.com vid skrivetid).

Framstående tweaks

Det finns en hel del förändringar som folk rekommenderar när de uppgraderas till en SSD. Efter att ha filtrerat ut några av de äldre grejerna gjorde vi en kort lista över tweaks som Linux distros inte har inkluderat som standard för SSD. Tre av dem innebär att du redigerar din fstab-fil, så backa upp innan du fortsätter med följande kommando:

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

Om något går fel kan du alltid ta bort den nya fstabfilen och ersätta den med en kopia av din säkerhetskopia. Om du inte vet vad det är eller vill du borsta på hur det fungerar, ta en titt på HTG Explains: Vad är Linux fstab och hur fungerar det??

Eschewing Access Times

Du kan hjälpa till att öka din SSDs liv genom att minska hur mycket operativsystemet skriver till disken. Om du behöver veta när varje fil eller katalog hittades senast kan du lägga till dessa två alternativ till din / etc / fstab-fil:

noatime, nodiratime

Lägg till dem tillsammans med de andra alternativen, och se till att de är alla separerade av kommatecken och inga mellanslag.

Aktiverar TRIM

Du kan aktivera TRIM för att hjälpa till att hantera prestanda på hårddisken på lång sikt. Lägg till följande alternativ i din fstab-fil:

kassera

Detta fungerar bra för ext4-filsystem, även på vanliga hårddiskar. Du måste ha en kärnversion av minst 2.6.33 eller senare; du är täckt om du använder Maverick eller Natty, eller har backports aktiverat på Lucid. Även om detta inte specifikt förbättrar initial benchmarking, bör det göra systemet bättre på lång sikt och så gjorde det vår lista.

tmpfs

Systemets cache lagras i / tmp. Vi kan berätta för fstab att montera detta i RAM som ett temporärt filsystem så att ditt system kommer att röra hårddisken mindre. Lägg till följande rad längst ner i din / etc / fstab-fil i en ny rad:

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

Spara din fstab-fil för att begå dessa ändringar.

Växla IO Schedulers

Ditt system skriver inte alla ändringar till disken omedelbart och flera förfrågningar köras i kö. Standardinmatnings-schemaläggaren - cfq - hanterar det här okej, men vi kan ändra det här till en som fungerar bättre för vår maskinvara.

Först lista vilka alternativ du har tillgång till med följande kommando, byt ut "X" med brevet på din rotddisk:

katt / sys / block / sdX / kö / schemaläggare

Min installation är på sda. Du bör se några olika alternativ.

Om du har tidsfrist bör du använda det, eftersom det ger dig en extra tweak längre ner i linjen. Om inte, bör du kunna använda noop utan problem. Vi måste berätta för operativsystemet att använda dessa alternativ efter varje start så vi måste redigera den rc.local-filen.

Vi använder nano, eftersom vi är bekväma med kommandoraden, men du kan använda någon annan textredigerare du gillar (gedit, vim, etc.).

sudo nano /etc/rc.local

Ovanför "exit 0" -linjen, lägg till dessa två rader om du använder deadline:

echo deadline> / sys / block / sdX / kö / schemaläggare

eko 1> / sys / block / sdX / kö / iosched / fifo_batch

Om du använder noop lägg till den här raden:

echo noop> / sys / block / sdX / kö / schemaläggare

Ännu en gång, byt ut "X" med rätt skrivbrev för din installation. Titta över allt för att se till att det ser bra ut.

Klicka sedan CTRL + O för att spara, sedan CTRL + X för att avsluta.

Omstart

För att alla dessa ändringar ska träda i kraft måste du starta om. Därefter borde du vara upptagen. Om något går fel och du inte kan starta, kan du systematiskt ångra alla ovanstående steg tills du kan starta om igen. Du kan även använda en LiveCD eller LiveUSB för att återställa om du vill.

Dina fstabförändringar kommer att genomföra din installations tid, även om det inte går att uppgradera, men din rc.local-ändring måste återinrättas efter varje uppgradering (mellan versioner).

Benchmarking Results

För att utföra referensvärdena, körde vi diskpaketet av test. Toppbilden för varje test är innan tweaking ext4-konfigurationen, och den undre bilden är efter tweaks och en omstart. Du får se en kort förklaring av vad testet mäter samt en tolkning av resultaten.

Stora filoperationer

Detta test komprimerar en 2GB-fil med slumpmässiga data och skriver den till disken. SSD-tweaksna här visar ungefär 40% förbättring.

IOzone simulerar filsystemets prestanda, i det här fallet genom att skriva en 8GB-fil. Återigen, en nästan 50% ökning.

Här läses en 8GB-fil. Resultaten är nästan samma som utan att justera ext4.

AIO-Stress testar asynkront inmatning och utmatning, med hjälp av en 2GB testfil och en 64KB rekordstorlek. Här är det nästan 200% ökning av prestanda jämfört med vanilj ext4!

Små filoperationer

En SQLite-databas skapas och PTS lägger till 12 500 poster till den. SSD-tweaksna härmed saktade ned prestandan med ca 10%.

Apache Benchmark-testen slumpmässigt läser av små filer. Det var cirka 25% prestationsvinst efter att ha optimerat vår SSD.

PostMark simulerar 25.000 filtransaktioner, 500 samtidigt vid varje tillfälle, med filstorlekar mellan 5 och 512KB. Detta simulerar web- och mailservrar ganska bra och vi ser en 16% prestationsökning efter tweaking.

FS-Mark ser 1000 filer med en totalstorlek på 1 MB och mäter hur många som kan skrivas och läsas i en ordinär tid. Våra tweaks ser en ökning, igen, med mindre filstorlekar. Om en 45% ökning med ext4 justeringar.

Filsystemåtkomst

Dbench benchmarks test filsystem samtal av kunder, som om hur Samba gör saker. Här är vaniljens ext4 prestanda sänkt med 75%, en viktig återgång i de förändringar vi gjort.

Du kan se att när antalet kunder går upp ökar prestandaförskjutningen.

Med 48 kunder stängde klyftan något mellan de två, men det finns fortfarande en mycket tydlig prestandaförlust av våra tweaks.

Med 128 kunder är prestandan nästan densamma. Du kan anse att våra tweaks kanske inte är idealiska för hemmabruk i denna typ av operation, men kommer att ge jämförbar prestanda när antalet kunder ökas kraftigt.

Detta test beror på kärnans AIO-åtkomstbibliotek. Vi har en förbättring på 20% här.

Här har vi en multi-threaded slumpmässig avläsning av 64 MB, och det finns en 200% ökning av prestanda här! Wow!

Medan du skriver 64 MB data med 32 trådar, har vi fortfarande en prestandaförbättring på 75%.

Compile Bench simulerar effekten av ålder på ett filsystem som representeras av att manipulera kärnträd (skapa, sammanställa, lappa, etc.). Här kan du se en betydande fördel genom den initiala skapandet av den simulerade kärnan, cirka 40%.

Dessa riktmärken mäter helt enkelt hur lång tid det tar att extrahera Linux-kärnan. Inte för mycket av en ökning av prestanda här.

Sammanfattning

De anpassningar vi gjorde till Ubuntus ut-of-the-box ext4-konfiguration hade en ganska stor inverkan. De största prestationsvinsterna fanns i riket av multi-threaded skriver och läser, liten fil läser och stor sammanhängande fil läser och skriver. Faktum är att den enda verkliga platsen vi såg en träff i prestanda var i enkla filsystem samtal, något Samba användare bör se upp för. Sammantaget verkar det vara en ganska stabil ökning av prestanda för saker som värd webbsidor och titta på / strömmande stora videor.

Tänk på att detta var specifikt med Ubuntu Natty 64-bit. Om ditt system eller SSD är annorlunda kan din körsträcka variera. Sammantaget verkar det som om de fstab- och IO-schemaläggningsjusteringar vi gjorde gjorde en lång väg till bättre prestanda, så det är nog värt ett försök på egen rigg.

Har du egna riktmärken och vill dela dina resultat? Har du en annan tweak vi inte vet om? Ljud ut i kommentarerna!