hur man justera din ssd i ubuntu för bättre prestanda

Det finns massor av tips ute för att anpassa 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 tweaks att visa den verkliga skillnaden.

Att jämföra vår disk, använde vi Phoronix Test Suite. Det är gratis och har en förvaringsplats för Ubuntu så att du inte behöver bygga från grunden för att köra snabba tester. Vi testade vårt system direkt efter en ny installation av Ubuntu Natty 64-bitars med standardparametrar för filsystemet ext4.

Vårt system specs var följande

Och, naturligtvis, SSD vi använde för att testa på var en 64GB OCZ Onyx enhet ($ 117 på Amazon.com i skrivande stund).

Det finns en hel del förändringar som människor rekommenderar vid uppgradering till en SSD. Efter att filtrera bort en del av de äldre saker, gjorde vi en kort lista över tweaks som Linux distributioner inte har inkluderat som standard för SSD-enheter. Tre av dem innebär redigera fstab, 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 fstab och ersätta den med en kopia av säkerhetskopian. Om du inte vet vad det är eller om du vill fräscha upp hur det fungerar, ta en titt på HTG förklarar: Vad är Linux fstab och hur fungerar det?

Undviker åtkomsttid

Du kan bidra till att öka livslängden på din SSD genom att minska hur mycket OS skriva till disk. Om du behöver veta när varje fil eller katalog senast tillgängliga, kan du lägga till dessa två alternativ till din / etc / fstab

noatime, nodiratime

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

Aktivera TRIM

Du kan aktivera TRIM för att hantera diskprestanda på lång sikt. Lägg till följande alternativ till fstab

kassera

Detta fungerar bra för ext4 filsystem, även på vanliga hårddiskar. Du måste ha en kärna version av åtminstone 2.6.33 eller senare, du omfattas om du använder Maverick eller Natty, eller har backports aktiverade på Lucid. Även om detta inte uttryckligen förbättra den grundläggande benchmarking, bör det göra systemet fungera bättre på lång sikt och så det gjorde vår lista.

tmpfs

Systemet cache lagras i / tmp. Vi kan tala om fstab för att montera detta i RAM som en tillfällig filsystem så att systemet kommer att beröra hårddisken mindre. Lägg till följande rad till botten av din / etc / fstab i en ny rad

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

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

Omkoppling IO Almanackor

Systemet skriver inte alla ändringarna till hårddisken omedelbart, och flera begäranden blir kö. Standard input-output-tids – CFQ – hanterar detta okej, men vi kan ändra detta till en som fungerar bättre för vår hårdvara.

Först lista vilka alternativ du har tillgängliga med följande kommando som ersätter “X” med bokstaven för rot-enhet

cat / sys / blockera / sdX / kö / schemaläggare

Min installation på sda. Du bör se ett par olika alternativ.

Om du har deadline, bör du använda den, eftersom det ger dig en extra tweak längre ner i raden. Om inte, bör du kunna använda noop utan problem. Vi måste tala om för operativsystemet att använda dessa alternativ efter varje uppstart så vi måste ändra rc.local fil.

Vi kommer att använda nano, eftersom vi är bekväm 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” linje, lägga till dessa två rader om du använder deadline

echo tidsfrist> / sys / blockera / sdX / kö / schemaläggare

echo 1> / sys / blockera / sdX / kö / iosched / fifo_batch

Om du använder noop, lägga till denna linje

echo Noop> / sys / blockera / sdX / kö / schemaläggare

Än en gång, ersätta “X” med lämplig enhetsbokstav för din installation. Se över allt för att se till att det ser bra ut.

Sedan slog CTRL + O för att spara, då CTRL + X för att avsluta.

Omstart

För att alla dessa förändringar att träda i kraft, måste du starta. Efter det, bör du vara redo. Om något går fel och du kan inte starta, kan du systematiskt ångra vart och ett av ovanstående steg tills du kan starta igen. Du kan även använda en LiveCD eller LiveUSB att återhämta sig om man vill.

Dina fstab förändringar kommer att fortsätta genom livet av installationen, även motstå uppgraderingar, men din rc.local förändring måste åter väckas efter varje uppgradering (mellan versioner).

För att utföra riktmärkena, körde vi disken svit av tester. Den översta bilden av varje test är innan tweaking ext4 konfiguration och nedre bilden är efter tweaks och en omstart. Du ser en kort förklaring av vad testet mäter liksom en tolkning av resultaten.

Stor fil Operations

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

IOzone simulerar filsystemet prestanda, i detta fall genom att skriva en 8GB fil. Återigen, en ökning med nästan 50%.

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

AIO-Stresstester asynkront ingång och utgång, med hjälp av ett 2GB testfil och en 64 KB rekord storlek. Här finns det nästan en ökning 200% i prestanda jämfört med vanilj ext4!

Liten fil Operations

En SQLite databas skapas och PTS lägger 12.500 poster till det. SSD tweaks här faktiskt långsammare prestanda med cirka 10%.

Apache Benchmark testar slumpmässigt läser av små filer. Det handlade om en 25% prestandavinst efter att optimera vår SSD.

Poststämpeln simulerar 25.000 fil transaktioner, 500 samtidigt vid en given tidpunkt, med filstorlekar mellan 5 och 512KB. Detta simulerar webb- och e-postservrar ganska bra, och vi ser en 16% prestandaökning efter tweaking.

FS-Mark tittar på 1000 filer med en total storlek på 1 MB och mäter hur många kan vara helt skrivs och läses i en förutbestämd tid. Våra tweaks se en ökning, återigen, med mindre filstorlekar. Om en ökning med 45% med justeringar ext4.

File System Access

Den Dbench riktmärken testfil systemanrop av kunder, ungefär som hur Samba gör saker. Här är vanilj ext4 resultat minskat med 75%, en större bakslag i de förändringar som vi gjort.

Du kan se det som antalet kunder går upp, prestanda avvikelse ökar.

Med 48 klienter, minskat gapet något mellan de två, men det finns fortfarande en mycket tydlig prestandaförlust av våra tweaks.

Med 128 kunder, är resultatet nästan densamma. Du kan resonera som våra tweaks inte kan vara perfekt för hemmabruk i denna typ av verksamhet, men kommer att ge jämförbar prestanda när antalet klienter är kraftigt förhöjd.

Detta test beror på kärnans AIO tillgång bibliotek. 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 ökning i prestanda här 200%! Wow!

När du skriver 64MB data med 32 trådar, fortfarande har vi en ökning i prestanda 75%.

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

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

Justeringarna vi gjort till Ubuntus out-of-the-box ext4 konfiguration hade ett starkt intryck. De största prestandavinster var i sfärer av flertrådade skriver och läser, liten fil läser och stora sammanhängande fil läser och skriver. I själva verket det enda verkliga platsen såg vi en träff i prestanda var i enkla filsystemet samtal, något Samba-användare bör se upp för. Sammantaget verkar det vara en ganska solid ökning av prestanda för saker som värd webbsidor och titta / strömmande stora videor.

Kom ihåg att detta var speciellt med Ubuntu Natty 64-bitars. Om ditt system eller SSD är annorlunda, kan din körsträcka variera. Totalt men det verkar som om fstab och IO schemaläggare justeringar gjorde vi gå en lång väg att bättre prestanda, så det är förmodligen värt ett försök på egen rigg.

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

Intressant! Det har varit trevligt att ha känt tweaks på jobbet i testerna,. Dvs. “The tweak noatime, nodiratime hjälpt i detta test” osv, så sätt kan vi kanske kan justera saker lite furthur att få bättre resultat.

Jag gjorde detta. Att vara en komplett Noob på Linux jag lyckades korrupta fstab första gången. Men sedan återställs det, se guide här: http://ubuntuforums.org/showthread.php?t=1340431 och allt gick enligt plan. Trevlig och mycket märkbar ökning av hastighet och jämnare gång. Kör Natty på PB Dot_se Netbook, 2GB RAM och 64bg ssd.

Som en chef: RAM endast

Det finns ingen anledning att använda både noatime och nodiratime, med hjälp av noatime innebär nodiratime.

Trevlig! Skillnaden märks nästan omedelbart.

Vad som gör detta speciellt för SSD-enheter, varför skulle vi inte vill att dessa prestandavinster på någon hårddisk?

Bra inlägg. Jag är nyfiken på I / O schemaläggare tweak … Jag kör på en Ubuntu 11.04 låda med en SSD byggd med LVM och LUKS för diskkryptering, per http://readm3.org/os/ubuntu/full-disk -encryption-lvm-luks … som ett resultat min fstab referenser filsystem via / dev / mapper / ubuntu-root och / dev / mapper / ubuntu-swap (logiska volymer inom volymgrupp). Några tankar om hur jag skulle justera I / O schemaläggare för dessa filsystem eller om det ens skulle vara relevant för LVM filsystem?

kryptering eller hastighet, välj en

rtfm också

Min SSD disk hålla förändras mellan sda och sdb. Kan jag redigera rc.local med UUID namn istället?

Det är ett skalskript, så att du kan använda kommandon för att kartlägga UUID till enhetsnamn. Detta bör fungera (har inte testat det)

echo tidsfrist> / sys / blockera / $ (/ sbin / blkid -U 6baddb0a-5246-47f7-964c-9b4c0e1c3447 | sed ‘s / \ / dev \ ///) / kö / schemaläggare

med liknande ersättare för sdX på de andra linjerna. Naturligtvis bör UUID på den linjen vara din UUID.

För alla, inklusive författare, 2 saker

1. “diratime” är en delmängd av “atime”, därför behöver du bara ge “noatime” för att stänga av båda,. 2. Eftersom alla eller nästan alla av detta är i kärnan, det gäller även alla andra Linux-distributioner (jag är en Slackware kille själv).

Till Lefty: SSD fördelar över hårddiskar är att alla utom den äldsta stöd TRIM / kassera och de har ingen signifikant söktid. Dessutom nyaste SSD: s är snabbare än även den snabbaste enskilda hårddiskar. (Även notera att SSD: er verkligen RAID-liknande insida, gör parallell R / W från flera flashchip, så att de är tekniskt fusk! 🙂

Å andra sidan, HDD fördelar är obegränsade skriver (på grund av magnetisk media) och mycket billigare kostnad / GB. Som sagt, i hardcore program som databaser, visar det sig att korrekt behandlad, hårddiskar och SSD: s misslyckas på ungefär samma takt-go figur! Dessutom har ett par riktigt nya hårddiskar tydligen genomfört TRIM / kassera, men tester har visat liten fördel på grund av hårddisken största tillgång problem över tiden är fragmentering, något som enheten har ingen kontroll över på en låg nivå AFAIK. (Det finns inget sådant som “fragmentering” på en SSD, och kör en defrag program på en är ett bra sätt att raka lite liv utanför det.)

I server arenan, saker och ting rör sig till att använda SSD: s för onlineåtkomst och hårddiskar som långsammare underlag butik, ett mellanting mellan swap och online backup, och ibland även för offline backup-traditionella domän tejp. Det viktiga här är att jag ser ingen anledning till en stationär eller dubbel-drive bärbara datorn inte kan göras för att göra samma sak, särskilt under Linux / UNIX!

Jag ser fram emot att komma över ett GUI program som trimmar ssd i Linux !!!!!!

Nummer fyra är det enda nummer vars engelska namn är samma antal bokstäver som antalet representerar.