Det finns många tips där ute för att finjustera din SSD i Linux och massor av anekdotiska rapporter om vad som fungerar och vad som inte fungerar. Vi körde våra egna riktmärken med några specifika justeringar för att visa dig den verkliga skillnaden.
Jämförelser
För att benchmarka vår disk använde vi Phoronix Test Suite . Det är gratis och har ett arkiv för Ubuntu så att du inte behöver kompilera från grunden för att köra snabba tester. Vi testade vårt system direkt efter en ny installation av Ubuntu Natty 64-bit med standardparametrarna för ext4-filsystemet.
Våra systemspecifikationer var som följer:
- AMD Phenom II fyrkärna @ 3,2 GHz
- MSI 760GM E51 moderkort
- 3.5 GB RAM
- AMD Radeon 3000 integrerad w / 512MB RAM
- Ubuntu Natty
Och naturligtvis var den SSD som vi testade på en 64 GB OCZ Onyx-enhet ( $ 117 på Amazon.com i skrivande stund).
Framstående tweaks
Det finns en hel del ändringar som folk rekommenderar när de uppgraderar till en SSD. Efter att ha filtrerat bort några av de äldre grejerna gjorde vi en kort lista med tweaks som Linux-distro inte har inkluderat som standard för SSD-enheter. Tre av dem involverar redigering av din fstab-fil, så backa upp det 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 fstab-filen och ersätta den med en kopia av din säkerhetskopia. Om du inte vet vad det är eller vill förklara hur det fungerar, ta en titt på det HTG förklarar: Vad är Linux fstab och hur fungerar det?
Eschewing Access Times
Du kan hjälpa till att öka livslängden på din SSD genom att minska hur mycket operativsystemet skriver till hårddisken. Om du behöver veta när varje fil eller katalog senast öppnades kan du lägga till dessa två alternativ i din / etc / fstab-fil:
noatime, nodiratime
Lägg till dem tillsammans med de andra alternativen och se till att alla är separerade med komma och inga mellanslag.
Aktiverar TRIM
Du kan aktivera TRIM för att hantera diskprestanda 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 på 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 inledande benchmarking, bör det få systemet att fungera bättre på lång sikt och så gjorde det vår lista.
Tmpfs
Systemets cache lagras i / tmp. Vi kan be fstab att montera detta i RAM-minnet som ett tillfälligt 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 standard, noatime, mode = 1777 0 0
Spara din fstab-fil för att göra dessa ändringar.
Växla IO-schemaläggare
Ditt system skriver inte alla ändringar på disken omedelbart, och flera förfrågningar får kö. Standardinmatnings-schemaläggaren - cfq - hanterar det här okej, men vi kan ändra det till en som fungerar bättre för vår hårdvara.
Först listar du vilka alternativ du har tillgängliga med följande kommando och ersätter "X" med bokstaven på din rotenhet:
cat / sys / block / sdX / queue / scheduler
Min installation är på sda. Du bör se några olika alternativ.
Om du har deadline bör du använda det, eftersom det ger dig en extra tweak längre ner på linjen. Om inte, bör du kunna använda noop utan problem. Vi måste be OS att använda dessa alternativ efter varje start så vi måste redigera rc.local-filen.
Vi använder nano, eftersom vi är bekväma med kommandoraden, men du kan använda vilken annan textredigerare du helst gillar (gedit, vim, etc.).
Plötslig / Etc / rc.ぉ eller l
Ovanför raden “exit 0”, lägg till dessa två rader om du använder deadline:
ekodatum> / sys / block / sdX / kö / schemaläggare
echo 1> / sys / block / sdX / queue / iosched / fifo_batch
Om du använder noop, lägg till den här raden:
echo noop> / sys / block / sdX / queue / scheduler
Återigen ersätter du "X" med rätt enhetsbokstav för din installation. Titta över allt för att se till att det ser bra ut.
Tryck sedan på CTRL + O för att spara och sedan CTRL + X för att avsluta.
Omstart
För att alla dessa ändringar ska träda i kraft måste du starta om. Efter det borde du vara klar. Om något går fel och du inte kan starta kan du systematiskt ångra vart och ett av ovanstående steg tills du kan starta om igen. Du kan även använda en LiveCD eller LiveUSB för att återhämta sig om du vill.
Dina fstab-ändringar kommer att fortsätta under installationens livslängd, även motstå uppgraderingar, men din rc.local-förändring måste återinstalleras efter varje uppgradering (mellan versionerna).
Jämförelseresultat
För att utföra riktmärken körde vi testserien. Den översta bilden i varje test är innan du justerar ext4-konfigurationen, och den nedre 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 filåtgärder
Detta test komprimerar en 2 GB-fil med slumpmässiga data och skriver den till disken. SSD-tweaks här visar i en ungefär 40% förbättring.
IOzone simulerar filsystemets prestanda, i det här fallet genom att skriva en 8 GB-fil. Återigen en nästan 50% ökning.
Här läses en 8 GB-fil. Resultaten är nästan desamma som utan att justera ext4.
AIO-Stress testar in- och utmatning asynkront med en 2 GB testfil och en 64 kB storlek. Här är det nästan 200% högre prestanda jämfört med vanilj ext4!
Små filåtgärder
En SQLite-databas skapas och PTS lägger till 12 500 poster i den. SSD-tweaks här saktade faktiskt ner prestanda med cirka 10%.
Apache-riktmärket testar slumpmässiga läsningar av små filer. Det var ungefär 25% prestandavinst efter optimering av vår SSD.
PostMark simulerar 25 000 filtransaktioner, 500 samtidigt vid varje given tidpunkt, med filstorlekar mellan 5 och 512 KB. Detta simulerar webb- och e-postservrar ganska bra, och vi ser en prestationsökning på 16% efter tweaking.
FS-Mark tittar på 1000 filer med en total storlek på 1 MB och mäter hur många som kan skrivas helt och läsas på förutbestämd tid. Våra tweaks ser igen en ökning med mindre filstorlekar. Cirka 45% ökning med ext4-justeringar.
Åtkomst till filsystem
Dbench-riktmärken testfilsystem samtal av klienter, ungefär som hur Samba gör saker. Här sänks vanilla ext4s prestanda med 75%, vilket är ett stort bakslag i de förändringar vi gjort.
Du kan se att när antalet klienter ökar, ökar prestationsavvikelsen.
Med 48 kunder stängdes klyftan något mellan de två, men det finns fortfarande en mycket uppenbar prestationsförlust av våra tweaks.
Med 128 klienter är resultatet nästan detsamma. Du kan resonera 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 ökar kraftigt.
Detta test beror på kärnans AIO-åtkomstbibliotek. vi har en 20% förbättring här.
Här har vi en flertrådad slumpmässig läsning av 64MB, och det finns en prestationsökning på 200% här! Wow!
När vi skriver 64 MB data med 32 trådar har vi fortfarande 75% högre prestanda.
Compile Bench simulerar ålderseffekten på ett filsystem som representeras av manipulering av kärnträd (skapa, kompilera, lappa etc.). Här kan du se en betydande fördel genom den första 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 justeringar som vi gjorde i Ubuntus ext-of-the-box ext4-konfiguration hade ganska stor inverkan. De största prestationsvinsterna var inom områden med flera trådar skriver och läser, små fil läser och stora sammanhängande fil läser och skriver. Faktum är att den enda riktiga platsen vi såg en träff i prestanda var i enkla filsystemsamtal, något som Samba-användare bör se upp för. Sammantaget verkar det vara en ganska solid ökning av prestanda för saker som webbsajter och titta på / streama 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 dock som om de justeringar av fstab och IO-schemaläggning vi gjort gör långt för bättre prestanda, så det är nog värt ett försök på din egen rigg.
Har du egna riktmärken och vill dela dina resultat? Har du en annan tweak som vi inte känner till? Ljud ut i kommentarerna!
