Je viens d'installer Xubuntu 16.04-64bit sur une seconde partition de mon ordinateur portable. J'ai remarqué que cela semblait parfois un peu lent, alors j'ai vérifié quel IO ordonnanceur il utilisait pour ce lecteur, qui s'est révélé être deadline
pour tous les lecteurs. J'ai quelques disques SSD et disques durs, donc je sais que la "date limite" est préférable pour les disques SSD et cfq
pour les disques durs.
J'ai démarré en 14.04 sur une autre partition et il utilise cfq
pour les disques en rotation et deadline
pour le SSD, comme il se doit. J'ai également consulté /etc/udev/rules.d
pour savoir si 14.04 utilisait une règle pour configurer le type de lecteur, mais elle n'y figurait pas. Je suppose donc que le noyau le fait.
Je me demande donc s'il s'agit d'un bogue ou utilise-t-il la "date limite" pour tout maintenant?
Mise à jour: Le commentaire que j'ai écrit sur /etc/udev/rules.d était une erreur. En fait, je me sers d'une règle udev pour modifier le planificateur (comme dans la réponse ci-dessous) en fonction du type de rotation depuis que j'ai commencé à utiliser un disque SSD, il y a quelques années. Je suppose que j'ai juste oublié ... de vieillir. Quoi qu’il en soit, l’une des références que j’ai utilisées est wiki d’optimisation Debian SSD .
Ne serait-ce pas une bonne idée si c'était inclus? Juste une suggestion!
Avec la version 14.04, le planificateur par défaut pour le noyau 3.13 a été modifié de CFQ à Deadline .
Il n’existe plus de noyau de serveur distinct et le sheduler CFQ n’est pas adapté à de nombreux scénarios d’utilisation du serveur, par exemple délais d’écriture KVM . Il existe même des régressions de performances sur le bureau avec périphériques USB .
L’équipe de noyau Ubuntu effectue régulièrement de nombreuses analyses de différentes charges de travail simulées sur différents systèmes de fichiers et différents planificateurs d’E/S afin de se faire une idée du meilleur choix de planificateur d’E/S générique. La réponse générale est qu'il n'y a pas de choix parfait de planificateur d'E/S pour une configuration générique parmi tous les types d'installations installés pour tous les types de supports. Les points saillants à retenir sont:
Les systèmes sont en train de migrer vers le SSD, c'est pourquoi aucun délai ni aucune échéance ne convient mieux. noop a moins de temps système que le délai imparti au processeur.
CFQ vs Date limite est un appel difficile. CFQ permet une plus grande flexibilité. Cependant, nous avons constaté que pour une gamme plus large d’opérations d’E/S simulées, les délais permettaient des latences plus faibles et un débit légèrement supérieur à celui de CFQ.
Je teste régulièrement les noyaux (chaque test de noyau prend plus de 3 jours) pour une gamme de systèmes de fichiers et de planificateurs d'E/S. À partir de cela, et d'autres données assorties, nous essayons de prendre une décision éclairée concernant le meilleur choix. Voir:
http://kernel.ubuntu.com/~cking/fs-tests/
Il existe des avantages/inconvénients pour tous les planificateurs d'E/S, de sorte que toute valeur par défaut n'est pas parfaite et l'équipe du noyau Ubuntu est toujours disposée à entrer dans le choix par défaut si des données et des raisons convaincantes nous indiquent de changer autrement.
Je ne sais pas pourquoi les développeurs ont décidé de choisir deadline
en tant que planificateur par défaut, peut-être parce que la plupart des nouveaux ordinateurs sont livrés avec un disque SSD, sur lequel les systèmes sont normalement installés. Vous pouvez définir le planificateur manuellement de cette façon, si vous ne l'avez pas déjà installé ... install gksu
name__:
Ouvrez un terminal et exécutez:
Sudo apt install gksu
Puis exécutez cette commande:
gksudo gedit /etc/udev/rules.d/60-schedulers.rules
Collez le texte suivant dans le fichier vide et enregistrez le fichier modifié.
# set cfq scheduler for rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="cfq"
# set deadline scheduler for non-rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"
Redémarrez le système d'exploitation et utilisez maintenant les planificateurs optimaux pour disques durs et SSD.