Il existe de nombreux conseils pour peaufiner votre SSD sous Linux et de nombreux rapports anecdotiques sur ce qui fonctionne et ce qui ne fonctionne pas. Nous avons exécuté nos propres benchmarks avec quelques ajustements spécifiques pour vous montrer la vraie différence.
Benchmarks
Pour comparer notre disque, nous avons utilisé le Suite de tests Phoronix. C’est gratuit et dispose d’un référentiel pour Ubuntu afin que vous n’ayez pas à compiler à partir de zéro pour exécuter des tests rapides. Nous avons testé notre système juste après une nouvelle installation d’Ubuntu Natty 64 bits en utilisant les paramètres par défaut du système de fichiers ext4.
Les spécifications de notre système étaient les suivantes:
- Quad-core AMD Phenom II à 3,2 GHz
- Carte mère MSI 760GM E51
- 3,5 Go de RAM
- AMD Radeon 3000 intégré avec 512 Mo de RAM
- Ubuntu Natty
Et, bien sûr, le SSD sur lequel nous avons testé était un disque OCZ Onyx de 64 Go (117 $ sur Amazon.com au moment de la rédaction).
Ajustements importants
Il y a quelques changements que les gens recommandent lors de la mise à niveau vers un SSD. Après avoir filtré certains des éléments les plus anciens, nous avons dressé une courte liste de modifications que les distributions Linux n’ont pas incluses par défaut pour les SSD. Trois d’entre eux impliquent la modification de votre fichier fstab, alors sauvegardez-le avant de continuer avec la commande suivante:
sudo cp / etc / fstab /etc/fstab.bak
En cas de problème, vous pouvez toujours supprimer le nouveau fichier fstab et le remplacer par une copie de votre sauvegarde. Si vous ne savez pas ce que c’est ou si vous voulez revoir son fonctionnement, jetez un œil à HTG Explains: Qu’est-ce que le fstab Linux et comment ça marche?
Éviter les temps d’accès
Vous pouvez contribuer à augmenter la durée de vie de votre SSD en réduisant la quantité d’écriture du système d’exploitation sur le disque. Si vous avez besoin de savoir quand chaque fichier ou répertoire a été accédé pour la dernière fois, vous pouvez ajouter ces deux options à votre fichier / etc / fstab:
noatime, nodiratime
Ajoutez-les avec les autres options et assurez-vous qu’elles sont toutes séparées par des virgules et sans espaces.
Activer TRIM
Vous pouvez activer TRIM pour vous aider à gérer les performances du disque sur le long terme. Ajoutez l’option suivante à votre fichier fstab:
Jeter
Cela fonctionne bien pour les systèmes de fichiers ext4, même sur les disques durs standard. Vous devez avoir une version du noyau d’au moins 2.6.33 ou version ultérieure; vous êtes couvert si vous utilisez Maverick ou Natty, ou si les rétroportages sont activés sur Lucid. Bien que cela n’améliore pas spécifiquement l’analyse comparative initiale, cela devrait permettre au système de mieux fonctionner à long terme et il a donc fait notre liste.
Tmpfs
Le cache système est stocké dans / tmp. Nous pouvons dire à fstab de le monter dans la RAM en tant que système de fichiers temporaire afin que votre système touche moins le disque dur. Ajoutez la ligne suivante au bas de votre fichier / etc / fstab dans une nouvelle ligne:
tmpfs / tmp Paramètres par défaut de tmpfs, noatime, mode = 1777 0 0
Enregistrez votre fichier fstab pour valider ces modifications.
Commutation des planificateurs d’E / S
Votre système n’écrit pas toutes les modifications sur le disque immédiatement et plusieurs demandes sont mises en file d’attente. Le planificateur d’entrée-sortie par défaut – cfq – gère cela correctement, mais nous pouvons le changer pour celui qui fonctionne mieux pour notre matériel.
Tout d’abord, répertoriez les options disponibles avec la commande suivante, en remplaçant «X» par la lettre de votre lecteur racine:
cat / sys / block / sdX / queue / planificateur
Mon installation est sur sda. Vous devriez voir quelques options différentes.
Si vous avez une date limite, vous devriez l’utiliser, car cela vous donne un ajustement supplémentaire plus tard. Sinon, vous devriez pouvoir utiliser noop sans problème. Nous devons dire au système d’exploitation d’utiliser ces options après chaque démarrage, nous devrons donc éditer le fichier rc.local.
Nous utiliserons nano, car nous sommes à l’aise avec la ligne de commande, mais vous pouvez utiliser n’importe quel autre éditeur de texte que vous aimez (gedit, vim, etc.).
sudo nano /etc/rc.local
Au-dessus de la ligne «exit 0», ajoutez ces deux lignes si vous utilisez la date limite:
échéance d’écho> / sys / block / sdX / queue / planificateur
echo 1> / sys / block / sdX / queue / iosched / fifo_batch
Si vous utilisez noop, ajoutez cette ligne:
echo noop> / sys / block / sdX / queue / planificateur
Encore une fois, remplacez «X» par la lettre de lecteur appropriée pour votre installation. Regardez tout pour vous assurer qu’il a l’air bien.
Ensuite, appuyez sur CTRL + O pour enregistrer, puis sur CTRL + X pour quitter.
Redémarrer
Pour que toutes ces modifications prennent effet, vous devez redémarrer. Après cela, vous devriez être prêt. Si quelque chose ne va pas et que vous ne pouvez pas démarrer, vous pouvez systématiquement annuler chacune des étapes ci-dessus jusqu’à ce que vous puissiez redémarrer. Vous pouvez même utiliser un LiveCD ou LiveUSB pour récupérer si vous le souhaitez.
Vos changements fstab dureront toute la vie de votre installation, même en résistant aux mises à niveau, mais votre changement rc.local devra être rétabli après chaque mise à jour (entre les versions).
Résultats d’analyse comparative
Pour effectuer les tests de performance, nous avons exécuté la suite de tests sur disque. L’image du haut de chaque test est avant de peaufiner la configuration ext4, et l’image du bas est après les ajustements et un redémarrage. Vous verrez une brève explication de ce que le test mesure ainsi qu’une interprétation des résultats.
Opérations sur les fichiers volumineux
Ce test compresse un fichier de 2 Go avec des données aléatoires et l’écrit sur le disque. Les modifications apportées au SSD montrent ici une amélioration d’environ 40%.
IOzone simule les performances du système de fichiers, dans ce cas en écrivant un fichier de 8 Go. Encore une fois, une augmentation de près de 50%.
Ici, un fichier de 8 Go est lu. Les résultats sont presque les mêmes que sans ajuster ext4.
AIO-Stress teste de manière asynchrone l’entrée et la sortie, à l’aide d’un fichier de test de 2 Go et d’une taille d’enregistrement de 64 Ko. Ici, les performances augmentent de près de 200% par rapport à vanilla ext4!
Opérations sur les petits fichiers
Une base de données SQLite est créée et PTS y ajoute 12 500 enregistrements. Les modifications apportées au SSD ont en fait ralenti les performances d’environ 10%.
L’Apache Benchmark teste les lectures aléatoires de petits fichiers. Il y a eu un gain de performances d’environ 25% après l’optimisation de notre SSD.
PostMark simule 25 000 transactions de fichiers, 500 simultanément à tout moment, avec des tailles de fichier comprises entre 5 et 512 Ko. Cela simule assez bien les serveurs Web et de messagerie, et nous constatons une augmentation des performances de 16% après les ajustements.
FS-Mark examine 1000 fichiers d’une taille totale de 1 Mo et mesure combien de fichiers peuvent être complètement écrits et lus dans un laps de temps prédéterminé. Nos ajustements voient une augmentation, encore une fois, avec des fichiers de plus petite taille. Augmentation d’environ 45% avec les ajustements ext4.
Accès au système de fichiers
Le Dbench teste les appels du système de fichiers par les clients, un peu comme la façon dont Samba fait les choses. Ici, les performances de vanilla ext4 sont réduites de 75%, un revers majeur dans les changements que nous avons apportés.
Vous pouvez voir que lorsque le nombre de clients augmente, l’écart de performances augmente.
Avec 48 clients, l’écart s’est quelque peu réduit entre les deux, mais il y a toujours une perte de performance très évidente par nos ajustements.
Avec 128 clients, les performances sont presque les mêmes. Vous pouvez penser que nos ajustements peuvent ne pas être idéaux pour un usage domestique dans ce type d’opération, mais fourniront des performances comparables lorsque le nombre de clients est considérablement augmenté.
Ce test dépend de la bibliothèque d’accès AIO du noyau. nous avons une amélioration de 20% ici.
Ici, nous avons une lecture aléatoire multi-thread de 64 Mo, et il y a une augmentation de 200% des performances ici! Hou la la!
Lors de l’écriture de 64 Mo de données avec 32 threads, nous avons toujours une augmentation de 75% des performances.
Compile Bench simule l’effet de l’âge sur un système de fichiers représenté par la manipulation des arbres du noyau (création, compilation, correction, etc.). Ici, vous pouvez voir un avantage significatif grâce à la création initiale du noyau simulé, environ 40%.
Ce benchmark mesure simplement le temps qu’il faut pour extraire le noyau Linux. Pas trop d’augmentation des performances ici.
Sommaire
Les ajustements que nous avons apportés à la configuration ext4 prête à l’emploi d’Ubuntu ont eu un impact considérable. Les gains de performances les plus importants se situaient dans les domaines des écritures et lectures multi-threadées, des lectures de petits fichiers et des lectures et écritures de fichiers contigus volumineux. En fait, le seul véritable endroit où nous avons vu un impact sur les performances était dans les simples appels de système de fichiers, ce à quoi les utilisateurs de Samba doivent faire attention. Dans l’ensemble, cela semble être une augmentation assez solide des performances pour des choses comme l’hébergement de pages Web et le visionnage / la diffusion de grandes vidéos.
Gardez à l’esprit que c’était spécifiquement avec Ubuntu Natty 64 bits. Si votre système ou SSD est différent, votre kilométrage peut varier. Dans l’ensemble, cependant, il semble que les ajustements du fstab et du planificateur d’E / S que nous avons effectués contribuent grandement à de meilleures performances, donc cela vaut probablement la peine d’essayer sur votre propre rig.
Vous avez vos propres benchmarks et souhaitez partager vos résultats? Avez-vous un autre ajustement que nous ne connaissons pas? Sonnez dans les commentaires!
