Nantes Hardware
Connectes toi !
Le Deal du moment : -41%
Cdiscount Mobile : offre 60Go à 9,99€/mois ...
Voir le deal
9.99 €

Optimisez Linux pour votre SSD

Aller en bas

Optimisez Linux pour votre SSD Empty Optimisez Linux pour votre SSD

Message par sioban le Mer 29 Juin 2011 - 20:18

Il existe plusieurs guides qui vous donne de bonnes pistes pour optimiser votre disque SSD sous Linux.
Voici, en condensé, ce que j'ai fait sur le mien et quelques pré-requis auxquels il faut penser au départ.

Tout d'abord, la fonction maître, c'est le TRIM : Online Discard.
Celui-ci ne fonctionne pleinement en mode transparent et en immédiat que sur les partitions ext4.
Pour les autres, il existe des supports partiels comme un mode manuel pour ext2/ext3 (qui nécessite de passer en read-only) ou un discard par
lot sur xfs.

Le plus simple et le plus logique à moins que vous soyez un aventurier, c'est bien de formater en ext4.

Pour les partitions autre que ext4 (comme ext2), les solutions sont proposées ici :
- TRIM manuel : http://www.ocztechnologyforum.com/forum/showthread.php?t=60882
- TRIM automatique : http://www.ocztechnologyforum.com/forum/showthread.php?p=479400#post479400

Ceci dit, passons aux optimisations :
Note : toutes ces opérations sont à réaliser en étant root.


Au niveau des partitions :

Commencez par sauvegarder le fichier /etc/fstab car toutes les modifications sont à faire dedans.
En cas de soucis, il suffira de rebooter sur une clé USB et de remettre le fichier original :

# cp /etc/fstab /etc/fstab.before_trim

- Il faut commencer par activer le TRIM pour les partitions.
Il faut tout d'abord être dans une version de noyau > 2.6.33.
Pour cela il faut ajouter la directive discard à la ligne de montage de la partition dans le fichier /etc/fstab :

# cat /etc/fstab

# / was on /dev/sda2 during installation
UUID=fa9ae8bd-2fd3-4d3f-bae7-54e66d4cf432 / ext4 discard,errors=remount-ro 0 1
# /boot was on /dev/sda1 during installation
UUID=a919a630-bfd2-4295-8db4-0b158370d95e /boot ext2 defaults 0 2

Pour vérifier que le TRIM est bien fonctionnel, un test est décrit ici : http://forums.gentoo.org/viewtopic-p-6228590.html#6228590

- Tant que l'on est dans le fichier /etc/fstab, on peut ajouter la directive noatime qui désactive l'écriture de l'information File access time modification.
Cela économise une écriture à chaque accès d'un fichier, ce qui n'est pas une bonne idée sur un SSD.

Certains logiciels ont besoin de cette information car ils se basent dessus pour fonctionner, c'est le cas de certains logiciels de mails (comme mutt).
Vous pouvez alors utiliser la directive relatime qui copie dans l'information File access time modification, celle de File modification ou de File creation.
L'information ne sera pas juste mais elle sera présente, c'est plus propre et c'est ce que j'ai choisi de faire.

Cette instruction est aussi utilisable sur les autres types de partitions comme ext2.
Plus d'info là dessus ici : https://wiki.archlinux.org/index.php/Fstab

# cat /etc/fstab

# / was on /dev/sda2 during installation


UUID=fa9ae8bd-2fd3-4d3f-bae7-54e66d4cf432 / ext4 relatime,discard,errors=remount-ro 0 1
# /boot was on /dev/sda1 during installation
UUID=a919a630-bfd2-4295-8db4-0b158370d95e /boot ext2 relatime,defaults 0
2

- Si on a assez de mémoire, on peut créer déplacer le répertoire /tmp en RAM pour cela il faut ajouter la directive tmpfs dans le fichier /etc/fstab

# cat /etc/fstab

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

Certaines personnes proposent aussi de mettre /var/tmp et /var/log en mémoire, ce que je déconseille personnellement à moins de n'avoir que faire des logs...
Mais c'est envisageable, il faudrait faire la même chose que pour /tmp.

Pour que toutes ces opérations soient prisent en compte, il faut rebooter.


Au niveau des paramètres du disque :

Il faut absolument changer le planificateur d'I/O (I/O Scheduler) qui est paramétré par défaut en anticipatory ou cfq pour des HDD afin de décroitre les temps de réponses en ajoutant des pauses entres chaque lecture, ce qui est contre productif sur un SSD et réduit les performances.

Il faut utiliser les directives deadline ou noop :
- Deadline va tenter de réordonner les lectures/écritures et noop ne fera rien de particulier.
- Deadline sera utile si vous voulez plus de performance et noop si vous voulez gagner en temps CPU (utile sur les petits eeePC par exemple).

J'ai personnellement choisi deadline.

Pour connaitre le mode actuel, il faut taper la commande suivante, la directive entre crochet est celle active (sda est mon disque SSD):

# cat /sys/block/sda/queue/scheduler
noop deadline [cfq
]

Pour l'activer de façon temporaire (jusqu'au prochain reboot)

# echo deadline > /sys/block/sda/queue/scheduler

# cat /sys/block/
sda/queue/scheduler
noop [deadline] cfq

En mode deadline, il y a une autre option à modifier fifo_batch qui est positionnée par défaut à une valeur élevée (16) afin de réduire les temps de recherche sur le disque mais qui augmente la latence. Sur un SSD il n'y pas de temps de recherche, on peut donc mettre une valeur basse.

# echo 1 > /sys/block/sda/queue/iosched/fifo_batch

Il y a plusieurs possibilités pour rendre les changements permanent, le plus simple est d'ajouter la commande au fichier /etc/rc.local.
Ce fichier est normalement exécuté automatiquement au démarrage.

# cat /etc/rc.local
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

# SSD Optimization
# Deadline is better than cfq, noop is another possibility
echo deadline > /sys/block/sda/queue/scheduler
# Works together with Deadline
echo 1 > /sys/block/sda/queue/iosched/fifo_batch

exit 0

On peut aussi ajouter une directive à GRUB (elevator=deadline) ce qui permet de profiter de ces optimisations dès le boot (/etc/rc.local est exécuté très tardivement) mais il faudra penser à le modifier lors d'un upgrade du noyau (voir http://itezer.com/blog/ubuntu-linux/125-four-tweaks-for-using-ubuntu-with-ssd.html).


Ext4 et les fichiers journaux
Ext4 est un système de fichier journalisé.
Il est possible de le désactiver si on le souhaite, toutefois vous risquez d'avoir des erreurs irrécupérables en cas de crash de l'os ou de coupures de courant. Je n'ai pas voulu le faire chez moi.

La procédure est décrite ici : http://cptl.org/wp/index.php/2010/03/30/tuning-solid-state-drives-in-linux/


Mode manuel pour Ext2
Le trim n'existe pas en mode automatique sur ext2, il faut donc utiliser un mode manuel.
Cela consiste en le démontage de la partition sur laquelle on veut effectuer le trim manuel puis a executer le script wiper.sh.
Ce script est dispo ici : http://www.ocztechnologyforum.com/forum/showthread.php?60882-wiper.sh-discussion-thread-%28Linux-TRIM-tool%29
L'opération est à réaliser une fois par semaine, c'est donc à mon sens, parfaitement scriptable en mode automatique.

Le script wiper.sh est fourni avec le paquet hdparm, il est disponible dans le répertoire /usr/share/doc/hdparm/contrib/wiper.sh.gz.

Il suffit alors de le décompresser :

# sudo su -
# gzip -d /usr/share/doc/hdparm/contrib/wiper.sh.gz
# mv usr/share/doc/hdparm/contrib/wiper.sh /usr/local/bin
# chmod +x /usr/local/bin/wiper.sh

Wiper.sh a besoin de gawk pour fonctionner
Si votre version a un bug ou si vous voulez absolument la dernière version d'hdparm, c'est par ici : http://sourceforge.net/projects/hdparm/

Il se lance comme ceci par exemple (/dev/sda1 = /boot chez moi et la partition est en etx2) :

[quote]# mount -o remount,ro /dev/sda1
# /usr/local/bin/wiper.sh --verbose --commit /dev/sda1
# mount -o remount,rw /dev/sda1
[/code]

Pour automatiser :
Créez le fichier trim dans /etc/crond.weekly avec le contenu suivant et rendez-le éxecutable.
Cela executera wiper.sh une fois par semaine pour la partition /boot qui est /dev/sda1 chez moi (la seule en ext2 pour moi) :

# sudo su -
# cd /etc/crond.weekly
# vi trim

Code:
#!/bin/sh

test -x /usr/local/bin/wiper.sh || exit 0
date >> /var/log/wiper.log
mount -o remount,ro /dev/sda1  >> /var/log/wiper.log 2>&1
/usr/local/bin/wiper.sh --verbose --please-prematurely-wear-out-my-ssd --commit /dev/sda1 >>/var/log/wiper.log
mount -o remount,rw /dev/sda1  >> /var/log/wiper.log 2>&1

# chmod +x trim

Attention, si vous faites une mise à jour de noyau lorsque la partition /boot est en mode lecture seulement, les modifications ne seront pas prises en compte...
Disktrim permet de faire la même chose en mode graphique (nécessite wiper.sh) : http://disktrim.sourceforge.net/

Au niveau de Firefox

Ceci n'est peut-être pas utile si vous êtes sur une connexion Internet lente et que vous redémarrez souvent.


  • Ouvrez Firefox ;
  • Tapez about:config dans la zone d'url ;
  • Acceptez l'avertissement ;
  • Cliquez avec le bouton droit de la souris dans n'importe quelle colonne ;
  • Selectionnez Nouvelle > Chaîne ;
  • Ajoutez browser.cache.disk.parent_directory et validez avec la touche entrée ;
  • Mettez /tmp comme chaîne ;
  • Redémarrez Firefox ;
  • Utilisez about:cache pour vérifier.


Une autre solution est de désactiver le cache de Firefox :
about:config

Change following :
  • browser.cache.disk.enable : false
  • browser.cache.disk.capacity : 0
  • browser.cache.offline.enable : false
  • browser.cache.offline.enable : 0
  • browser.cache.memory.enable : true (default)

La plupart de ces informations proviennent de ces posts sur le forum :
- http://www.ocztechnologyforum.com/forum/showthread.php?54379-Linux-Tips-tweaks-and-alignment&highlight=linux
- http://itezer.com/blog/ubuntu-linux/125-four-tweaks-for-using-ubuntu-with-ssd.html
- http://www.mydellmini.com/forum/dell-mini-9-hardware-upgrades/6741-tips-tweaking-solid-state-drive-performance-linux.html
Vous y trouverez plus de détails et des liens vers d'autres idées comme l'alignement des partitions que je n'ai pas testé.


Dernière édition par sioban le Mar 26 Juil 2011 - 15:35, édité 5 fois
sioban
sioban
Coadmin
Coadmin

Nombre de messages : 21060
Localisation : Perdue dans les genres

Revenir en haut Aller en bas

Optimisez Linux pour votre SSD Empty Re: Optimisez Linux pour votre SSD

Message par sioban le Mer 29 Juin 2011 - 20:27

Petit test de performances :

Sans les optimisations disque :

# hdparm -t /dev/sda

/dev/sda:
Timing buffered disk reads: 502 MB in 3.00 seconds = 167.18 MB/sec

Avec IOScheduler sur deadline :

# echo deadline > /sys/block/sda/queue/scheduler
# hdparm -t /dev/sda

/dev/sda:
Timing buffered disk reads: 508 MB in 3.01 seconds = 168.62 MB/sec

Avec fifo_batch de réglé :

# echo 1 > /sys/block/sda/queue/iosched/fifo_batch
# hdparm -t /dev/sda

/dev/sda:
Timing buffered disk reads: 508 MB in 3.00 seconds = 169.24 MB/sec

Donc pas de pertes et un léger gain Wink
Mais ce n'est pas la perf que je visais mais bien la réduction des écritures
sioban
sioban
Coadmin
Coadmin

Nombre de messages : 21060
Localisation : Perdue dans les genres

Revenir en haut Aller en bas

Optimisez Linux pour votre SSD Empty Re: Optimisez Linux pour votre SSD

Message par robin44 le Jeu 30 Juin 2011 - 8:26

Merci pour ça Sio Wink
robin44
robin44
Modérateur
Modérateur

Nombre de messages : 6577
Localisation : Missillac

Revenir en haut Aller en bas

Optimisez Linux pour votre SSD Empty Re: Optimisez Linux pour votre SSD

Message par sioban le Jeu 30 Juin 2011 - 11:04

J'ai fait le test pour vérifier si le trim fonctionne :

Création d'un fichier de 52 Mo :

# dd if=/dev/urandom of=tempfile count=100 bs=512k oflag=direct
100+0 enregistrements lus
100+0 enregistrements écrits
52428800 octets (52 MB) copiés, 16,9317 s, 3,1 MB/s

Récuperation d'un numéro de secteur (le 1er) :
# hdparm --fibmap tempfile

tempfile:
filesystem blocksize 4096, begins at LBA 497664; assuming 512 byte sectors.
byte_offset begin_LBA end_LBA sectors
0 55553024 55554047 1024
524288 55565312 55566335 1024
1048576 55582720 55584767 2048
2097152 55924736 55928831 4096
4194304 55916544 55924735 8192
8388608 55941120 55957503 16384
16777216 56121344 56190975 69632

Lecture du contenu de ce secteur afin de voir les données qui y ont été écrites :
# hdparm --read-sector 55553024 /dev/sda

/dev/sda:
reading sector 55553024: succeeded
1a8a 5ee0 da4f 4be2 f03b 4269 3214 7d77
07e7 bd97 539b 231b 163a 3a6f af7d fa39
f4a0 0dc5 86eb 1a05 2b9d 68dd 9688 050e
6db8 7e97 d6b4 b2f0 2005 60d5 cbfc 6712
41cc 6eed 52ec 7e00 101f a2fc cb74 dd01
f595 98e8 2bb9 dfe7 a8be dd03 6cd9 e487
176e 065f d3e6 251a caa0 8064 b387 11e5
25dd 7d20 3e24 4427 7dcf 661a f01b eaa9 [...]

Suppression du fichier :
# rm tempfile

Synchronisation du disque à cause des caches :
# sync

Relecture du secteur pour voir si le contenu a été récupéré :
# hdparm --read-sector 55553024 /dev/sda

/dev/sda:
reading sector 55553024: succeeded
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 [...]

J'ai des zéros, c'est donc le contenu a bien été supprimé et que le TRIM a bien fonctionné sinon j'aurais encore les données sur le secteur.
Il se peut que le TRIM ne soit pas immédiat, tout dépend de la technologie utilisée par le SSD, chez moi c'est immédiat !

sioban
sioban
Coadmin
Coadmin

Nombre de messages : 21060
Localisation : Perdue dans les genres

Revenir en haut Aller en bas

Optimisez Linux pour votre SSD Empty Re: Optimisez Linux pour votre SSD

Message par Zeitoon le Jeu 30 Juin 2011 - 11:11

Respect
Zeitoon
Zeitoon
Administrateur
Administrateur

Nombre de messages : 32169
Localisation : N : 47.08.13 O : 01.40.48

https://www.nhfr.org

Revenir en haut Aller en bas

Optimisez Linux pour votre SSD Empty Re: Optimisez Linux pour votre SSD

Message par pmgamer le Jeu 30 Juin 2011 - 11:59

Respect
pmgamer
pmgamer
NHFR All Stars
NHFR All Stars

Nombre de messages : 12433
Localisation : Nulle Part Ailleurs

Revenir en haut Aller en bas

Optimisez Linux pour votre SSD Empty Re: Optimisez Linux pour votre SSD

Message par Remuald le Jeu 30 Juin 2011 - 17:50

pas mieux Respect
Remuald
Remuald
Coadmin
Coadmin

Nombre de messages : 31630
Localisation : anywhere

Revenir en haut Aller en bas

Optimisez Linux pour votre SSD Empty Re: Optimisez Linux pour votre SSD

Message par sioban le Mar 26 Juil 2011 - 14:23

Je viens de refaire la procédure avec l'intel et je gagne nettement en perf par rapport au vertex 2 (mais le gap est le même entre les optimisations):

Avant optimisation
# hdparm -t /dev/sda

/dev/sda:
Timing buffered disk reads: 728 MB in 3.00 seconds = 242.29 MB/sec


Après optimisation
# hdparm -t /dev/sda

/dev/sda:
Timing buffered disk reads: 732 MB in 3.00 seconds = 243.76 MB/sec

A ce sujet la grosse différence cette fois c'est que j'ai aligné les partitions et les filesystem.
sioban
sioban
Coadmin
Coadmin

Nombre de messages : 21060
Localisation : Perdue dans les genres

Revenir en haut Aller en bas

Optimisez Linux pour votre SSD Empty Re: Optimisez Linux pour votre SSD

Message par sioban le Mar 26 Juil 2011 - 14:35

Ajout d'infos concernant ext2/trim mode manuel, la suppression du journal en ext4 et une méthode alternative pour le cache de firefox.
sioban
sioban
Coadmin
Coadmin

Nombre de messages : 21060
Localisation : Perdue dans les genres

Revenir en haut Aller en bas

Optimisez Linux pour votre SSD Empty Re: Optimisez Linux pour votre SSD

Message par Mimi le Jeu 28 Juil 2011 - 8:49

je me note ce post pour une réinstallation futur sur mon SSD
Mimi
Mimi
NHFR All Stars
NHFR All Stars

Nombre de messages : 9886
Localisation : Rezé

Revenir en haut Aller en bas

Optimisez Linux pour votre SSD Empty Re: Optimisez Linux pour votre SSD

Message par robin44 le Jeu 28 Juil 2011 - 12:03

Punaise le gain de performances est conséquent par rapport à ton ancien SSD Shocked
robin44
robin44
Modérateur
Modérateur

Nombre de messages : 6577
Localisation : Missillac

Revenir en haut Aller en bas

Optimisez Linux pour votre SSD Empty Re: Optimisez Linux pour votre SSD

Message par sioban le Jeu 28 Juil 2011 - 14:39

yep mais c'est du test hdparm, je me demande d'ailleurs si c'est vraiment parlant :

Using hdparm - Speed Test

Before any of your drive's settings are changed a speed test should be done, so we can refer to it later to make sure that the drive's speed has been increased and we are not just wasting our time.
To do this hdparm can perform two benchmarks:

The speed of reading directly from the Linux buffer cache without disk access. (-t option)
The speed of reading through the buffer cache to the disk without any prior caching of data. (-T option)

The first shows us an indication of the throughput of the processor, cache, and memory of the system under test. The second measures how fast the drive can sustain sequential data reads, without any filesystem overhead.It is best to run these tests together as the second results are corrected for the first. It is also as usual to run these a couple of times to get accurate results. Here is the command you need to use:

hdparm -Tt /dev/hdb

You should some results similar to these below (results from PII 350Mhz with year old hard disk):

/dev/hdb:
Timing buffer-cache reads: 128 MB in 1.25 seconds =102.40 MB/sec
Timing buffered disk reads: 64 MB in 16.70 seconds = 3.83 MB/sec
sioban
sioban
Coadmin
Coadmin

Nombre de messages : 21060
Localisation : Perdue dans les genres

Revenir en haut Aller en bas

Optimisez Linux pour votre SSD Empty Re: Optimisez Linux pour votre SSD

Message par sioban le Jeu 28 Juil 2011 - 14:44

en fait c'est exactement l'inverse :
-T = cached reads
-t = buffered reads

donc le -t est pertinent pour la lecture.
sioban
sioban
Coadmin
Coadmin

Nombre de messages : 21060
Localisation : Perdue dans les genres

Revenir en haut Aller en bas

Optimisez Linux pour votre SSD Empty Re: Optimisez Linux pour votre SSD

Message par Contenu sponsorisé


Contenu sponsorisé


Revenir en haut Aller en bas

Revenir en haut


 
Permission de ce forum:
Vous ne pouvez pas répondre aux sujets dans ce forum