Depuis que je reçois mon disque SSD (Crucial M4 - 256 Go), le problème est qu’il écrit aussi lentement que Windows 7 sur un 486 lorsqu’il fait quelque chose avec de petits fichiers. J'ai réussi à "réparer" cela dans Windows 7 en installant le pilote / service Intel Rapid Storage Technology.
Cependant, sous Linux (sous Ubuntu 13.04), il ne semble pas y avoir de pilote pour cela. J'ai essayé beaucoup de solutions différentes et aucune ne semble avoir fonctionné jusqu'à présent.
Mon SSD est partitionné en une seule partition EXT4, montée en tant que /. J'ai un disque dur séparé de 2 To sur lequel je monte / home
Voici quelques informations que j'ai saisies concernant les tailles de bloc:
# sudo blockdev --getbsz /dev/sda
> 4096
# sudo hdparm -I /dev/sda | grep -i physical
> Physical Sector size: 512 bytes
Mon entrée fstab pour mon SSD ressemble à ceci:
UUID=c954288b-e1bd-4d3b-93ab-6a688210d070 / ext4 errors=remount-ro,relatime,barrier=0,noatime,nodiratime,discard,commit=120 0 1
Comme vous pouvez le constater avec les options, j'ai essayé beaucoup de choses, mais aucune ne semble fonctionner correctement. Pour donner un exemple: installer ViM avec "apt-get install vim" a pris plus de 2 minutes.
Une mise à niveau complète par apt-get dist a pris plus de 4 heures et demie. J'ai utilisé Ubuntu sur mon disque dur normal (5 200 tr / min) et le résultat est BEAUCOUP plus rapide que cela.
Selon Parted, ma partition est correctement alignée. J'ai vérifié en utilisant les commandes suivantes:
# sudo parted /dev/sda
<parted> align-check opt
partition: 1
> aligned 1
En outre, lors de l'exécution d'iotop chaque fois que le SSD est "occupé", jbd2 consomme en permanence environ 99 à 100% du temps.
Si quelqu'un pouvait faire la lumière sur cette question, ce serait totalement génial!
edit: Quelques infos supplémentaires:
Lancer hdparm -t / dev / sda donne le résultat suivant (ce qui me convient parfaitement)
Timing buffered disk reads: 680 MB in 3.01 seconds = 226.16 MB/sec
Sortie iotop en mode veille:
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
2346 be/4 harold 0.00 B/s 31.04 K/s 0.00 % 0.00 % chrome
1 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % init
2 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kthreadd]
3 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksoftirqd/0]
5 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/0:0H]
7 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/u:0H]
Parfois, lors de l’exécution d’installations d’applications ou d’autres tâches lourdes, ce processus "jbd2" permet de dévorer toutes les ressources, tandis que l’application en cours d’exécution (par exemple, mysqld ~ 4%)
Ce qui est étrange, c’est que, parfois, cela fonctionne très bien (j’ai essayé de reproduire le problème pour publier les résultats ici, mais apparemment, cela se produit à des moments aléatoires). Je mettrai à jour la sortie de iotop ci-dessous avec les résultats de la situation suivante.
Je sens que mon ordinateur me traîne maintenant :(
edit2: J'ai oublié d'ajouter quelques extras (merci Craig Watson)
Le contenu de mon fichier /etc/rc.local ressemble à ceci:
echo deadline > /sys/block/sda/queue/scheduler
fstrim -v /
exit 0
Et dans / etc / default / grub, j'ai:
GRUB_CMDLINE_LINUX_DEFAULT="elevator=deadline"
Après avoir d'abord essayé le planificateur, j'ai ajouté la partie fstrim également, car je n'ai toujours pas obtenu de bons résultats avec le planificateur.
Merci d'avance.
Harold.
Réponses:
Essayez de changer votre planificateur d'E / S:
Ajoutez-le ensuite aux valeurs par défaut de Grub pour qu'il soit chargé au démarrage:
Changer
GRUB_CMDLINE_LINUX_DEFAULTen:Et courir:
sudo update-grub2Vérifiez également votre utilisation de la mémoire RAM - vous pourriez échanger votre disque SSD, ce qui (à long terme) pourrait avoir des effets néfastes. Si vous avez assez de RAM, vous pouvez définir swappiness sur zéro pour que la RAM ne soit pas utilisée sauf si vous êtes complètement à court de RAM:
Référence: http://apcmag.com/how-to-maximise-ssd-performance-with-linux.htm
la source