Ci sono molti suggerimenti là fuori per modificare il tuo SSD in Linux e molti rapporti aneddotici su cosa funziona e cosa no. Abbiamo eseguito i nostri benchmark con alcune modifiche specifiche per mostrarti la vera differenza.
Punti di riferimenti
Per eseguire il benchmark del nostro disco, abbiamo utilizzato l'estensione Phoronix Test Suite . È gratuito e ha un repository per Ubuntu, quindi non è necessario compilare da zero per eseguire test rapidi. Abbiamo testato il nostro sistema subito dopo una nuova installazione di Ubuntu Natty a 64 bit utilizzando i parametri predefiniti per il file system ext4.
Le nostre specifiche di sistema erano le seguenti:
- Quad-core AMD Phenom II a 3,2 GHz
- MSI 760GM E51 motherboard
- 3.5 GB RAM
- AMD Radeon 3000 integrata con 512 MB di RAM
- Ubuntu Natty
E, naturalmente, l'SSD su cui abbiamo eseguito il test era un'unità OCZ Onyx da 64 GB ( $ 117 su Amazon.com al momento della scrittura).
Importanti modifiche
Ci sono alcune modifiche che le persone consigliano durante l'aggiornamento a un SSD. Dopo aver filtrato alcune delle cose più vecchie, abbiamo creato un breve elenco di modifiche che le distribuzioni Linux non hanno incluso come impostazioni predefinite per gli SSD. Tre di questi comportano la modifica del file fstab, quindi eseguine 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 cosa sia o vuoi rispolverare come funziona, dai un'occhiata HTG spiega: cos'è l'fstab di Linux e come funziona?
Evitare i tempi di accesso
Puoi aumentare la durata del tuo SSD riducendo la quantità di scrittura del sistema operativo su disco. Se hai bisogno di sapere quando è stato eseguito l'ultimo accesso a ciascun file o directory, puoi aggiungere queste due opzioni al tuo 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. È necessario disporre di una versione del kernel almeno 2.6.33 o successiva; sei coperto se stai utilizzando Maverick o Natty, oppure hai i backport abilitati su Lucid. Sebbene ciò non migliori in modo specifico il benchmarking iniziale, dovrebbe rendere il sistema più performante nel lungo periodo e quindi ha fatto la nostra lista.
Tmpfs
La cache di sistema è archiviata in / tmp. Possiamo dire a fstab di montarlo nella RAM come 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.
Cambio degli scheduler di I / O
Il sistema non scrive immediatamente tutte le modifiche sul disco e più richieste vengono messe in coda. Lo scheduler di input-output predefinito - cfq - gestisce questo bene, ma possiamo cambiarlo in uno che funzioni meglio per il nostro hardware.
Innanzitutto, elenca le opzioni che hai a disposizione con il seguente comando, sostituendo "X" con la lettera del tuo root drive:
cat / sys / block / sdX / queue / scheduler
La mia installazione è su sda. Dovresti vedere alcune opzioni diverse.
Se hai una scadenza, dovresti usarla, poiché ti dà un ulteriore aggiustamento più avanti. In caso contrario, dovresti essere in grado di usare noop senza problemi. Dobbiamo dire al sistema operativo di utilizzare queste opzioni dopo ogni avvio, quindi dovremo modificare il file rc.local.
Useremo nano, dato che siamo a nostro agio 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 "uscita 0", aggiungi queste due righe se stai utilizzando la scadenza:
scadenza echo> / 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. Controlla tutto per assicurarti che sia a posto.
Quindi, premi CTRL + O per salvare, quindi CTRL + X per uscire.
Ricomincia
Affinché tutte queste modifiche abbiano effetto, è necessario riavviare. Dopodiché, dovresti essere pronto. Se qualcosa va storto e non è possibile eseguire l'avvio, è possibile annullare sistematicamente ciascuno dei passaggi precedenti fino a quando non è possibile riavviare. Puoi anche usare un file LiveCD o LiveUSB per il ripristino se vuoi.
Le modifiche a fstab continueranno per tutta la durata dell'installazione, anche resistendo agli aggiornamenti, ma la modifica a rc.local dovrà essere ripristinata dopo ogni aggiornamento (tra le versioni).
Risultati del benchmarking
Per eseguire i benchmark, abbiamo eseguito la suite di test su disco. L'immagine in alto di ogni test è prima di modificare la configurazione ext4, e l'immagine in basso è dopo le modifiche e un riavvio. Vedrai una breve spiegazione di ciò che misura il test e un'interpretazione dei risultati.
Operazioni su file di grandi dimensioni
Questo test comprime un file da 2 GB con dati casuali e lo scrive su disco. Le modifiche 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. Ancora una volta, un aumento di quasi il 50%.
Qui viene letto un file da 8 GB. I risultati sono quasi gli stessi di senza regolare 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'è un aumento di quasi il 200% delle prestazioni rispetto a vanilla ext4!
Operazioni su piccoli file
Viene creato un database SQLite e PTS aggiunge 12.500 record ad esso. Le modifiche all'SSD qui hanno effettivamente rallentato le prestazioni di circa il 10%.
Il benchmark Apache verifica le letture casuali di piccoli file. C'è stato un aumento delle prestazioni di circa il 25% dopo l'ottimizzazione del nostro SSD.
PostMark simula 25.000 transazioni di file, 500 contemporaneamente in un dato momento, con dimensioni di file comprese tra 5 e 512 KB. Questo simula abbastanza bene i server web e di posta e vediamo un aumento delle prestazioni del 16% dopo il tweaking.
FS-Mark esamina 1000 file con una dimensione totale di 1 MB e misura quanti possono essere completamente scritti e letti in un periodo di tempo prestabilito. Le nostre modifiche vedono un aumento, ancora una volta, con file di dimensioni inferiori. Aumento di circa il 45% con le regolazioni ext4.
Accesso al file system
I benchmark di Dbench testano le chiamate del file system da parte dei client, un po 'come il modo in cui Samba fa le cose. In questo caso, le prestazioni di vanilla ext4 vengono ridotte del 75%, una battuta d'arresto importante nei cambiamenti che abbiamo apportato.
Puoi vedere che all'aumentare del numero di client, la discrepanza nelle prestazioni aumenta.
Con 48 client, il divario si è in qualche modo ridotto tra i due, ma c'è ancora una perdita di prestazioni molto evidente dalle nostre modifiche.
Con 128 client, le prestazioni sono quasi le stesse. Si può pensare che le nostre modifiche potrebbero non essere ideali per l'uso domestico in questo tipo di operazione, ma forniranno prestazioni comparabili quando il numero di clienti aumenta notevolmente.
Questo test dipende dalla libreria di accesso AIO del kernel. abbiamo un miglioramento del 20% qui.
Qui abbiamo una lettura casuale multi-thread di 64 MB e qui c'è un aumento del 200% delle prestazioni! Wow!
Durante la scrittura di 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, applicazione di patch, 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 Linux. Non un aumento eccessivo delle prestazioni qui.
Sommario
Le modifiche che abbiamo apportato alla configurazione ext4 di Ubuntu hanno avuto un notevole impatto. I maggiori guadagni in termini di prestazioni si sono verificati nel campo delle scritture e letture multi-thread, delle letture di piccoli file e delle letture e scritture di file contigui di grandi dimensioni. In effetti, l'unico vero posto in cui abbiamo visto un successo nelle prestazioni era in semplici chiamate al file system, qualcosa a cui gli utenti di Samba dovrebbero prestare attenzione. Nel complesso, sembra essere un aumento piuttosto solido delle prestazioni per cose come l'hosting di pagine Web e la visione / lo streaming di video di grandi dimensioni.
Tieni presente che questo era specificamente con Ubuntu Natty a 64 bit. Se il tuo sistema o SSD è diverso, il tuo chilometraggio potrebbe variare. Nel complesso, tuttavia, sembra che le regolazioni di fstab e IO scheduler che abbiamo apportato siano molto utili per migliorare le prestazioni, quindi probabilmente vale la pena provare sul tuo impianto.
Hai i tuoi parametri di riferimento e vuoi condividere i tuoi risultati? Hai un'altra modifica di cui non siamo a conoscenza? Suona nei commenti!
