(Linux - Ubuntu 13.04) Incroyable SSD avec de petits fichiers


4

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.


Juste un contrôle de sécurité, qu'est-ce qui vous fait penser que le temps est passé sur les E / S de disque plutôt que sur le trafic réseau? Vos appels apt-get peuvent être extrêmement lents si votre réseau est encombré pour une raison quelconque, par exemple.
ChrisInEdmonton

Le téléchargement des fichiers est incroyablement rapide. C'est la partie "décompression" qui est vraiment lente :(
Harold

Réponses:


1

Essayez de changer votre planificateur d'E / S:

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

Ajoutez-le ensuite aux valeurs par défaut de Grub pour qu'il soit chargé au démarrage:

sudo nano /etc/default/grub

Changer GRUB_CMDLINE_LINUX_DEFAULTen:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash elevator=deadline"

Et courir: sudo update-grub2

Vé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:

sudo echo 0 > /proc/sys/vm/swappiness

Référence: http://apcmag.com/how-to-maximise-ssd-performance-with-linux.htm


Merci pour la réponse. En fait, j'ai aussi essayé cela (j'ai complètement oublié de poster, je mettrai à jour le post). J'ai le programmateur dans mon fichier rc.local et j'utilise également "fstrim -v /" (après que le programmateur a prouvé qu'il ne fonctionnait pas non plus de temps en temps).
Harold

La sortie mémoire semble bien aussi. Sur 8 concerts, il y a 3,4 en utilisation, 4,6 gratuits. La zone d'échange est également de 8 Go, 0 en cours d'utilisation.
Harold
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.