Hoe u uw SSD in Ubuntu kunt aanpassen voor betere prestaties

Er zijn veel tips voor het aanpassen van je SSD in Linux en veel anekdotische rapporten over wat werkt en wat niet. We hebben onze eigen benchmarks uitgevoerd met een paar specifieke tweaks om je het echte verschil te laten zien.

benchmarks

Om onze schijf te benchmarken, hebben we de Phoronix-testsuite gebruikt. Het is gratis en heeft een repository voor Ubuntu, zodat je niet vanaf nul hoeft te compileren om snelle tests uit te voeren. We testten ons systeem direct na een nieuwe installatie van Ubuntu Natty 64-bit met behulp van de standaardparameters voor het ext4-bestandssysteem.

Onze systeemspecificaties waren als volgt:

• AMD Phenom II quad-core @ 3,2 GHz
• MSI 760GM E51-moederbord
• 3,5 GB RAM
• AMD Radeon 3000 geïntegreerd met 512 MB RAM
• Ubuntu Natty

En, natuurlijk, de SSD die we testten was een 64 GB OCZ Onyx-schijf ($ 117 op Amazon.com op het moment van schrijven).

Prominente verbeteringen

Er zijn nogal wat wijzigingen die mensen aanbevelen bij het upgraden naar een SSD. Na het filteren van enkele van de oudere dingen, hebben we een korte lijst met tweaks gemaakt die Linux-distro's niet als standaard voor SSD's bevatten. Bij drie daarvan moet je je fstab-bestand bewerken, dus maak een back-up voordat je verder gaat met de volgende opdracht:

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

Als er iets misgaat, kunt u altijd het nieuwe fstab-bestand verwijderen en vervangen door een kopie van uw back-up. Als je niet weet wat dat is of als je wilt weten hoe het werkt, kijk dan eens naar HTG Explains: Wat is de Linux-fstab en hoe werkt het?

Toegangstijden verlengen

U kunt de levensduur van uw SSD helpen verlengen door te verminderen hoeveel het besturingssysteem naar schijf schrijft. Als u wilt weten wanneer elk bestand of elke map voor het laatst is geopend, kunt u deze twee opties toevoegen aan uw bestand / etc / fstab:

noatime, nodiratime

Voeg ze samen met de andere opties toe en zorg dat ze allemaal gescheiden zijn door komma's en geen spaties.

TRIM inschakelen

U kunt TRIM inschakelen om op lange termijn de schijfprestaties te beheren. Voeg de volgende optie toe aan uw fstab-bestand:

afdanken

Dit werkt goed voor ext4-bestandssystemen, zelfs op standaard harde schijven. Je moet een kernelversie van minstens 2.6.33 of later hebben; je bent gedekt als je Maverick of Natty gebruikt of als back-ups zijn ingeschakeld op Lucid. Hoewel dit niet specifiek de initiële benchmarking verbetert, zou het het systeem op de lange termijn beter moeten doen presteren en daarom heeft het onze lijst gemaakt.

tmpfs

De systeemcache wordt opgeslagen in / tmp. We kunnen fstab vertellen dat dit in het RAM-geheugen moet worden geplaatst als een tijdelijk bestandssysteem, zodat uw systeem de harde schijf minder raakt. Voeg de volgende regel toe aan de onderkant van uw / etc / fstab-bestand in een nieuwe regel:

tmpfs / tmp tmpfs standaardinstellingen, noatime, modus = 1777 0 0

Sla uw fstab-bestand op om deze wijzigingen door te voeren.

Schakelen tussen IO-planners

Uw systeem schrijft niet meteen alle wijzigingen op schijf en meerdere aanvragen worden in de wachtrij geplaatst. De standaard invoer-uitvoerplanner - cfq - verwerkt dit goed, maar we kunnen dit veranderen naar een die beter werkt voor onze hardware.

Noteer eerst welke opties beschikbaar zijn met de volgende opdracht en vervang "X" door de letter van uw rootstation:

cat / sys / block / sdX / queue / scheduler

Mijn installatie staat op sda. Je zou een paar verschillende opties moeten zien.

Als je een deadline hebt, zou je dat moeten gebruiken, omdat het je een extra tweak verderop in de rij geeft. Als dat niet het geval is, zou u Noop zonder problemen moeten kunnen gebruiken. We moeten het besturingssysteem laten weten dat deze opties na elke opstart moeten worden gebruikt, dus we moeten het bestand rc.local bewerken.

We zullen nano gebruiken, omdat we ons vertrouwd voelen met de opdrachtregel, maar je kunt elke andere teksteditor gebruiken die je wilt (gedit, vim, etc.).

sudo nano /etc/rc.local

Boven de regel "exit 0" voegt u deze twee regels toe als u de deadline gebruikt:

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

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

Als je noop gebruikt, voeg je deze regel toe:

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

Vervang "X" opnieuw door de juiste stationsaanduiding voor uw installatie. Kijk over alles om er zeker van te zijn dat het er goed uitziet.

Raak vervolgens CTRL + O aan om op te slaan en vervolgens CTRL + X om te stoppen.

Herstarten

Voordat al deze wijzigingen van kracht worden, moet u opnieuw opstarten. Daarna zou je helemaal klaar moeten zijn. Als er iets misgaat en u kunt niet opstarten, kunt u systematisch alle bovenstaande stappen ongedaan maken totdat u weer kunt opstarten. Je kunt zelfs een LiveCD of LiveUSB gebruiken om te herstellen als je wilt.

Uw fstab-wijzigingen zullen de levensduur van uw installatie doorstaan, zelfs bij upgrades, maar uw rc.local-wijziging moet opnieuw worden ingesteld na elke upgrade (tussen versies).

Resultaten benchmarken

Voor het uitvoeren van de benchmarks hebben we de reeks tests uitgevoerd. De bovenste afbeelding van elke test is vóór het aanpassen van de ext4-configuratie, en de onderste afbeelding is na de tweaks en een herstart. U zult een korte uitleg zien van wat de test meet, evenals een interpretatie van de resultaten.

Grote bestandsbewerkingen

Deze test comprimeert een bestand van 2 GB met willekeurige gegevens en schrijft het naar de schijf. De SSD-tweaks tonen hier een verbetering van ongeveer 40%.

IOzone simuleert de prestaties van het bestandssysteem, in dit geval door een bestand van 8 GB te schrijven. Nogmaals, een toename van bijna 50%.

Hier wordt een bestand van 8 GB gelezen. De resultaten zijn bijna hetzelfde als zonder het aanpassen van ext4.

AIO-Stress test asynchroon de invoer en uitvoer met behulp van een testbestand van 2 GB en een recordgrootte van 64 KB. Hier is de prestatieverhouding bijna 200% hoger dan bij vanille ext4!

Kleine bestandsbewerkingen

Er wordt een SQLite-database gemaakt en PTS voegt er 12.500 records aan toe. De SSD-tweaks hier vertraagden de prestaties met ongeveer 10%.

De Apache Benchmark test willekeurige leest van kleine bestanden. Er was ongeveer 25% prestatiewinst na het optimaliseren van onze SSD.

PostMark simuleert 25.000 bestandstransacties, tegelijkertijd 500 op elk willekeurig moment, met bestandsgrootten tussen 5 en 512KB. Dit simuleert web- en mailservers vrij goed, en we zien een prestatieverhoging van 16% na tweaken.

FS-Mark kijkt naar 1000 bestanden met een totale grootte van 1MB en meet hoeveel er volledig kunnen worden geschreven en gelezen in een vooraf ingestelde hoeveelheid tijd. Onze tweaks zien een toename, opnieuw, met kleinere bestandsgroottes. Ongeveer een toename van 45% met ext4-aanpassingen.

Toegang tot bestandssysteem

De Dbench benchmarks testen bestandssysteemoproepen door clients, een beetje zoals hoe Samba dingen doet. Hier worden de prestaties van vanilla ext4 met 75% teruggebracht, een grote terugval in de veranderingen die we hebben doorgevoerd.

U kunt zien dat wanneer het aantal clients stijgt, het prestatieverschil toeneemt.

Met 48 clients sloot de kloof enigszins tussen de twee, maar er is nog steeds een zeer duidelijk prestatieverlies door onze tweaks.

Met 128 clients is de uitvoering bijna hetzelfde. U kunt redeneren dat onze tweaks misschien niet ideaal zijn voor thuisgebruik in dit soort bewerkingen, maar vergelijkbare prestaties bieden wanneer het aantal clients aanzienlijk wordt verhoogd.

Deze test is afhankelijk van de AIO-toegangsbibliotheek van de kernel. we hebben hier een verbetering van 20%.

Hier hebben we een multi-threaded random read van 64MB, en de prestaties zijn hier 200% beter! Wauw!

Tijdens het schrijven van 64 MB aan gegevens met 32 ​​threads, hebben we nog steeds een prestatieverbetering van 75%.

Compile Bench simuleert het effect van leeftijd op een bestandssysteem zoals weergegeven door het manipuleren van kernelbomen (maken, compileren, patchen, enz.). Hier zie je een significant voordeel door de eerste creatie van de gesimuleerde kernel, ongeveer 40%.

Deze benchmarks meten eenvoudig hoe lang het duurt om de Linux-kernel te extraheren. Niet te veel van een toename van de prestaties hier.

Samenvatting

De aanpassingen die we hebben gedaan aan de out4-versie van Ubuntu's ext4-configuratie hadden nogal een impact. De grootste prestatiewinsten waren op het gebied van schrijven en lezen met meerdere threads, kleine bestandsmeldingen en grote aaneengesloten lees- en schrijfbewerkingen van bestanden. In feite was de enige echte plaats die we een hit in de prestaties zagen, in eenvoudige bestandsysteemoproepen, iets waar Samba-gebruikers op moesten letten. Over het algemeen lijkt het een vrij solide toename in prestaties te zijn voor zaken als het hosten van webpagina's en het bekijken / streamen van grote video's.

Houd er rekening mee dat dit specifiek met Ubuntu Natty 64-bits was. Als uw systeem of SSD anders is, kan uw aantal kilometers variëren. Al met al lijkt het erop dat de fstab en IO scheduleraanpassingen die we hebben gemaakt een lange weg naar betere prestaties gaan, dus het is waarschijnlijk de moeite van het proberen waard op je eigen rig.

Heeft u uw eigen benchmarks en wilt u uw resultaten delen? Heb je nog een andere tweak waarvan we niets weten? Geluid in de reacties!