Come modificare il tuo SSD in Ubuntu per prestazioni migliori

Ci sono un sacco di suggerimenti là fuori per modificare il tuo SSD in Linux e molti resoconti aneddotici su cosa funziona e cosa no. Abbiamo eseguito i nostri benchmark con alcune modifiche specifiche per mostrarti la vera differenza.

benchmark

Per eseguire il benchmark del nostro disco, abbiamo utilizzato la Phoronix Test Suite. È gratuito e ha un repository per Ubuntu in modo da non dover compilare da zero per eseguire test rapidi. Abbiamo testato il nostro sistema subito dopo una nuova installazione di Ubuntu Natty 64-bit utilizzando i parametri predefiniti per il file system ext4.

Le nostre specifiche di sistema erano le seguenti:

• AMD Phenom II quad-core a 3.2 GHz
• Scheda madre MSI 760GM E51
• 3,5 GB di RAM
• AMD Radeon 3000 integrato con 512 MB di RAM
• Ubuntu Natty

E, naturalmente, l'SSD su cui abbiamo provato era un disco OCZ Onyx da 64 GB ($ 117 su Amazon.com al momento della scrittura).

Prominent Tweaks

Ci sono alcune modifiche che le persone raccomandano durante l'aggiornamento a un SSD. Dopo aver filtrato alcune delle cose più vecchie, abbiamo fatto un breve elenco di modifiche che le distribuzioni Linux non hanno incluso come default per gli SSD. Tre di questi riguardano la modifica del file fstab, quindi esegui il backup prima di continuare con il seguente comando:

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

Se qualcosa va storto, puoi sempre eliminare il nuovo file fstab e sostituirlo con una copia del tuo backup. Se non sai di cosa si tratta o vuoi approfondire come funziona, dai un'occhiata a HTG Explains: Che cos'è Linux fstab e come funziona?

Evitare i tempi di accesso

Puoi contribuire ad aumentare la durata del tuo SSD riducendo quanto il sistema operativo scrive su disco. Se è necessario sapere quando è stato effettuato l'ultimo accesso a ciascun file o directory, è possibile aggiungere queste due opzioni al file / etc / fstab:

noatime, nodiratime

Aggiungili insieme alle altre opzioni e assicurati che siano tutti separati da virgole e senza spazi.

Abilitazione TRIM

È possibile abilitare TRIM per aiutare a gestire le prestazioni del disco a lungo termine. Aggiungi la seguente opzione al tuo file fstab:

scartare

Funziona bene per i file system ext4, anche su dischi rigidi standard. Devi avere una versione del kernel di almeno 2.6.33 o successiva; sei coperto se usi Maverick o Natty o se hai abilitato i backport su Lucid. Anche se questo non migliora in modo specifico il benchmark iniziale, dovrebbe rendere il sistema più performante nel lungo periodo e quindi ha fatto il nostro elenco.

tmpfs

La cache di sistema è memorizzata in / tmp. Possiamo dire a fstab di montarlo nella RAM come un file system temporaneo in modo che il tuo sistema tocchi meno il disco rigido. Aggiungi la seguente riga in fondo al tuo file / etc / fstab in una nuova riga:

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

Salva il tuo file fstab per confermare queste modifiche.

Commutazione degli scheduler IO

Il tuo sistema non scrive immediatamente tutte le modifiche sul disco e più richieste vengono messe in coda. Lo schedulatore di input-output predefinito - cfq - gestisce questo aspetto, ma possiamo cambiarlo con uno che funziona meglio per il nostro hardware.

Innanzitutto, elenca le opzioni disponibili con il seguente comando, sostituendo "X" con la lettera dell'unità root:

cat / sys / block / sdX / queue / scheduler

La mia installazione è su sda. Dovresti vedere alcune opzioni differenti.

Se hai una scadenza, dovresti usarla, dato che ti dà un ulteriore aggiustamento su tutta la linea. In caso contrario, dovresti essere in grado di usare noop senza problemi. Dobbiamo dire al sistema operativo di usare queste opzioni dopo ogni avvio, quindi dovremo modificare il file rc.local.

Useremo nano, dal momento che siamo a posto con la riga di comando, ma puoi usare qualsiasi altro editor di testo che ti piace (gedit, vim, ecc.).

sudo nano /etc/rc.local

Sopra la riga "exit 0", aggiungi queste due righe se stai utilizzando la scadenza:

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

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

Se stai usando noop, aggiungi questa riga:

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

Ancora una volta, sostituire "X" con la lettera di unità appropriata per l'installazione. Guarda tutto per assicurarti che abbia un bell'aspetto.

Quindi, premi CTRL + O per salvare, quindi CTRL + X per uscire.

Ricomincia

Affinché tutte queste modifiche diventino effettive, è necessario riavviare. Dopo ciò, dovresti essere tutto pronto. Se qualcosa va storto e non è possibile avviare, è possibile annullare sistematicamente ciascuno dei passaggi precedenti fino a quando non è possibile riavviare. Puoi anche utilizzare un LiveCD o LiveUSB per recuperare se vuoi.

Le tue modifiche fstab permetteranno la vita dell'installazione, nonostante gli aggiornamenti, ma il tuo cambio rc.local dovrà essere ripristinato dopo ogni aggiornamento (tra le versioni).

Risultati di benchmarking

Per eseguire i benchmark, abbiamo eseguito la suite di test del disco. L'immagine in alto di ogni test è prima di modificare la configurazione di ext4 e l'immagine in basso è dopo le modifiche e un riavvio. Vedrai una breve spiegazione di ciò che il test misura e un'interpretazione dei risultati.

Grandi operazioni sui file

Questo test comprime un file da 2 GB con dati casuali e lo scrive su disco. I miglioramenti apportati all'SSD qui mostrano un miglioramento di circa il 40%.

IOzone simula le prestazioni del file system, in questo caso scrivendo un file da 8 GB. Di nuovo, un aumento di quasi il 50%.

Qui, viene letto un file da 8 GB. I risultati sono quasi gli stessi senza la regolazione di ext4.

AIO-Stress verifica in modo asincrono input e output, utilizzando un file di test da 2 GB e una dimensione del record di 64 KB. Qui, c'è quasi un aumento del 200% delle prestazioni rispetto a van4 ext4!

Piccole operazioni sui file

Viene creato un database SQLite e PTS aggiunge 12.500 record. I miglioramenti apportati all'SSD qui hanno effettivamente rallentato le prestazioni di circa il 10%.

Il benchmark di Apache verifica le letture casuali di piccoli file. C'è stato un aumento delle prestazioni del 25% dopo aver ottimizzato il nostro SSD.

PostMark simula 25.000 transazioni di file, 500 simultaneamente in qualsiasi momento, con dimensioni di file tra 5 e 512 KB. Questo simula abbastanza bene server web e mail, e vediamo un aumento delle prestazioni del 16% dopo la messa a punto.

FS-Mark analizza 1000 file con una dimensione totale di 1 MB e misura quanti possono essere completamente scritti e letti in un periodo di tempo prestabilito. I nostri tweaks vedono un aumento, ancora una volta, con file di dimensioni minori. Circa un aumento del 45% con le regolazioni ext4.

Accesso al file system

I benchmark di Dbench testano le chiamate del sistema di file da parte dei client, un po 'come il modo in cui Samba fa le cose. Qui, le prestazioni di vanilla ext4 sono ridotte del 75%, un grave ostacolo alle modifiche che abbiamo apportato.

È possibile notare che con l'aumento del numero di client, la discrepanza delle prestazioni aumenta.

Con 48 clienti, il divario si è in qualche misura chiuso tra i due, ma c'è ancora una evidente perdita di prestazioni dovuta ai nostri ritocchi.

Con 128 client, le prestazioni sono quasi le stesse. Si può ragionevolmente pensare che i nostri ritocchi potrebbero non essere ideali per l'uso domestico in questo tipo di operazione, ma forniranno prestazioni comparabili quando il numero di clienti è notevolmente aumentato.

Questo test dipende dalla libreria di accesso AIO del kernel. qui abbiamo un miglioramento del 20%.

Qui, abbiamo una lettura casuale a più thread di 64 MB, e qui c'è un aumento del 200% delle prestazioni! Wow!

Mentre scriviamo 64 MB di dati con 32 thread, abbiamo ancora un aumento del 75% delle prestazioni.

Compile Bench simula l'effetto dell'età su un file system rappresentato dalla manipolazione degli alberi del kernel (creazione, compilazione, patching, ecc.). Qui, puoi vedere un vantaggio significativo attraverso la creazione iniziale del kernel simulato, circa il 40%.

Questo benchmark misura semplicemente quanto tempo ci vuole per estrarre il kernel di Linux. Qui non c'è un aumento troppo significativo delle prestazioni.

Sommario

Gli aggiustamenti apportati alla configurazione ext4 out-of-the-box di Ubuntu hanno avuto un impatto notevole. I maggiori guadagni in termini di prestazioni sono stati i reami di scritture e letture multi-threaded, letture di file di piccole dimensioni e letture e scritture di file contigui di grandi dimensioni. In effetti, l'unico vero luogo in cui abbiamo visto un successo nelle prestazioni era in semplici chiamate al file system, qualcosa a cui gli utenti Samba dovrebbero fare attenzione. Nel complesso, sembra essere un aumento piuttosto solido delle prestazioni per cose come l'hosting di pagine Web e la visione / streaming di video di grandi dimensioni.

Tieni presente che questo era specificamente con Ubuntu Natty 64-bit. Se il tuo sistema o SSD è diverso, il tuo chilometraggio può variare. Nel complesso, tuttavia, sembra che le regolazioni dello scheduler fstab e IO abbiano fatto un lungo cammino verso prestazioni migliori, quindi probabilmente vale la pena provare sul tuo impianto.

Hai i tuoi benchmark e vuoi condividere i tuoi risultati? Hai un altro tweak di cui non siamo a conoscenza? Risuonare nei commenti!