web-dev-qa-db-fra.com

Sélection d'un planificateur d'E/S Linux

J'ai lu qu'il était soi-disant possible de changer le planificateur d'E/S pour un périphérique particulier sur un noyau en cours d'exécution en écrivant dans/sys/block/[disque]/file d'attente/planificateur. Par exemple, je peux voir sur mon système:

anon@anon:~$ cat /sys/block/sda/queue/scheduler 
noop anticipatory deadline [cfq]

que la valeur par défaut est le programmateur de mise en file d'attente tout à fait juste. Ce que je me demande, c'est s'il est utile d'inclure les quatre planificateurs dans mon noyau personnalisé. Il semblerait qu’il n’y ait aucun intérêt à avoir plus d’un ordonnanceur compilé à moins que le noyau ne soit suffisamment intelligent pour sélectionner le bon ordonnanceur pour le bon matériel, en particulier l’ordonnanceur 'noop' pour les disques à base flash et disque dur.

Est-ce le cas?

linuxlinux-kernelscheduling
80
Robert S. Barnes

Comme indiqué dans /usr/src/linux/Documentation/block/switching-sched.txt , le planificateur d'E/S de tout périphérique en mode bloc peut être modifié au moment de l'exécution. Il peut y avoir une certaine latence car les demandes du planificateur précédent sont toutes vidées avant de mettre le nouveau planificateur en service, mais elles peuvent être modifiées sans problème même lorsque le périphérique est fortement utilisé.

# cat /sys/block/hda/queue/scheduler
noop deadline [cfq]
# echo anticipatory > /sys/block/hda/queue/scheduler
# cat /sys/block/hda/queue/scheduler
noop [deadline] cfq

Idéalement, il n'y aurait qu'un seul ordonnanceur pour satisfaire tous les besoins. Il ne semble pas exister encore. Le noyau n'a souvent pas suffisamment de connaissances pour choisir le meilleur planificateur pour votre charge de travail:

  • noop est souvent le meilleur choix pour les périphériques bloc sauvegardés en mémoire (par exemple, les disques ramd) et les autres supports non rotatifs (flash) pour lesquels essayer de replanifier les E/S est une perte de ressources.
  • deadline est un planificateur léger qui essaie de fixer une limite stricte à la latence
  • cfq essaie de maintenir l'équité de la bande passante d'E/S à l'échelle du système

La valeur par défaut était anticipatory pendant longtemps, et elle a fait l'objet de nombreux ajustements, mais a été supprimée dans 2.6.33 (début 2010). cfq est devenu la valeur par défaut il y a quelque temps, car ses performances sont raisonnables et l'équité est un bon objectif pour les systèmes multi-utilisateurs (et même les ordinateurs de bureau mono-utilisateur). Pour certains scénarios - les bases de données sont souvent utilisées à titre d’exemples, car elles ont généralement leurs propres schémas de planification et d’accès, et constituent souvent le la plupart service important (qui se soucie donc de l’équité?) - anticipatory a une longue expérience en matière de réglage pour de meilleures performances sur ces charges de travail et deadline transmet très rapidement toutes les demandes au périphérique sous-jacent.

107
ephemient

Il est possible d'utiliser une règle udev pour laisser le système choisir le planificateur en fonction de certaines caractéristiques du hw.
Un exemple de règle udev pour les SSD et autres disques non rotatifs pourrait ressembler à

# set noop scheduler for non-rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop"

dans un nouveau fichier de règles udev (par exemple, /etc/udev/rules.d/60-ssd-scheduler.rules). Cette réponse est basée sur debian wiki

Pour vérifier si les disques ssd utiliseraient la règle, il est possible de vérifier au préalable l'attribut trigger: 

for f in /sys/block/sd?/queue/rotational; do printf "$f "; cat $f; done
19
Dani_l

L'objectif du support du noyau est de pouvoir les essayer sans redémarrer. vous pouvez ensuite exécuter des charges de travail de test via le système, mesurer les performances, puis en faire le standard pour votre application.

Sur le matériel moderne de niveau serveur, seul le noop semble être utile. Les autres semblent plus lents dans mes tests.

7
MarkR

Vous pouvez définir cela au démarrage en ajoutant le paramètre "elevator" à la cmdline du noyau (comme dans le fichier grub.cfg).

Exemple:

elevator=deadline

Cela fera de «date limite» le planificateur d'E/S par défaut pour tous les périphériques en mode bloc.

Si vous souhaitez interroger ou modifier le planificateur après le démarrage du système, ou si vous souhaitez utiliser un planificateur différent pour un périphérique de bloc spécifique, je vous recommande d'installer et d'utiliser l'outil ioschedset pour simplifier cela.

https://github.com/kata198/ioschedset

Si vous êtes sur Archlinux, il est disponible dans aur:

https://aur.archlinux.org/packages/ioschedset

Quelques exemples d'utilisation:

# Get i/o scheduler for all block devices
[username@hostname ~]$ io-get-sched
sda:    bfq
sr0:    bfq

# Query available I/O schedulers
[username@hostname ~]$ io-set-sched --list
mq-deadline kyber bfq none

# Set sda to use "kyber"
[username@hostname ~]$ io-set-sched kyber /dev/sda
Must be root to set IO Scheduler. Rerunning under Sudo...

[Sudo] password for username:
+ Successfully set sda to 'kyber'!

# Get i/o scheduler for all block devices to assert change
[username@hostname ~]$ io-get-sched
sda:    kyber
sr0:    bfq

# Set all block devices to use 'deadline' i/o scheduler
[username@hostname ~]$ io-set-sched deadline
Must be root to set IO Scheduler. Rerunning under Sudo...

+ Successfully set sda to 'deadline'!
+ Successfully set sr0 to 'deadline'!

# Get the current block scheduler just for sda
[username@hostname ~]$ io-get-sched sda
sda:    mq-deadline

L'utilisation devrait être explicite. Les outils sont autonomes et ne nécessitent que bash.

J'espère que cela t'aides!

EDIT: Disclaimer, ce sont des scripts que j'ai écrits.

0
Tim Savannah