Réglage du planificateur d'E/S sous Linux : mq-deadline, none et BFQ

Le planificateur d'E/S Linux détermine l'ordre dans lequel les requêtes de lecture et d'écriture parviennent à votre périphérique de stockage, et le choix approprié dépend presque entièrement de votre matériel. Utilisez none pour NVMe, mq-deadline pour les SSD SATA et les disques durs exécutant des charges de travail mixtes, et bfq lorsque vous devez empêcher un processus d'épuiser les ressources des autres. Ce guide explique le fonctionnement des trois principaux planificateurs, comment choisir celui qui correspond à votre charge de travail, et comment les régler et vérifier le résultat.

Si vous souhaitez un guide pratique avant de lire la suite, cette vidéo présente les bases du changement et du test des planificateurs depuis le terminal.

En quoi mq-deadline, none et BFQ diffèrent-ils ?

Chaque planificateur traite les requêtes selon une stratégie différente. C'est en connaissant leurs différences que vous pourrez faire un choix éclairé, plutôt que d'utiliser ce que le noyau a sélectionné au démarrage.

mq-deadline

Le mq-deadline planificateur veille à ce qu’aucune requête n’attende indéfiniment. Il gère des files d’attente triées distinctes pour les lectures et les écritures, en les classant par adresse de bloc logique (LBA) afin de réduire le temps de recherche, et impose des délais : 500 ms pour les lectures et 5 secondes pour les écritures par défaut. Lorsqu’une requête atteint son délai, elle passe en tête de la file d’attente.

Les lectures ont la priorité sur les écritures, car les lectures bloquent généralement l'application tandis que les écritures sont traitées de manière asynchrone. Pour éviter que les écritures ne soient complètement négligées, le planificateur traite un lot d'écritures en retard après un nombre défini de lectures. Il en résulte une faible latence constante, ce qui en fait un choix idéal pour les serveurs de bases de données et toute charge de travail combinant lectures et écritures.

none

Le none planificateur ne fait pratiquement rien. Il transmet les requêtes directement au périphérique selon le principe « premier entré, premier sorti », sans réorganisation, fusion ni hiérarchisation. Cela convient aux disques NVMe modernes, qui gèrent leurs propres files d’attente internes et peuvent suivre des dizaines de milliers de requêtes en cours simultanément. La suppression de la couche de planification logicielle offre le chemin le plus court possible entre l’application et le périphérique, ce qui correspond exactement aux besoins des charges de travail NVMe à haut débit.

Le hic, c'est que cela ne fonctionne que lorsque le matériel est capable de s'organiser intelligemment de lui-même. Sur les disques durs ou les SSD SATA dotés de files d'attente peu profondes, le fait de ne pas recourir au réordonnancement logiciel détériore généralement les performances, au lieu de les améliorer.

BFQ

BFQ (Budget Fair Queuing) privilégie l'équité. Au lieu de tranches de temps, il attribue à chaque processus un budget mesuré en secteurs de disque. Les lectures séquentielles volumineuses se voient attribuer des budgets plus importants pour maintenir le débit, tandis que les tâches sensibles à la latence reçoivent des budgets plus modestes afin d'être traitées rapidement, et une boucle de rétroaction ajuste les budgets au fur et à mesure de l'exécution.

BFQ garantit la réactivité des tâches interactives même sous une charge importante, de sorte que la lecture vidéo ou une requête de base de données reste fluide pendant qu’un transfert de fichier volumineux s’exécute en arrière-plan. Cette équité a un coût en termes de CPU. Sa surcharge par requête est d’environ 1,9 microseconde, soit environ trois fois celle de mq-deadline, et sur un cœur ARM plus lent, cette surcharge limite le débit bien en dessous de ce que le même planificateur atteint sur une puce x86 rapide. Sur les serveurs où le débit brut et l'efficacité du CPU priment, ce compromis est difficile à justifier.

Choisir un planificateur adapté à votre charge de travail

Deux éléments déterminent le planificateur approprié : votre matériel de stockage et le modèle d'accès de votre application. Commencez par le matériel. Si le périphérique réorganise déjà les requêtes, comme un disque NVMe doté d'un micrologiciel compatible, la planification logicielle ne fait qu'ajouter une surcharge, ce qui none l'option logicielle l'emporte. Sur les disques durs rotatifs, où le temps de recherche est prépondérant, le réordonnancement logiciel réduit la latence, donc mq-deadline ou bfq sont les meilleurs choix. Les SSD SATA se situent entre les deux : plus rapides que les disques durs, mais sans les files d'attente profondes de NVMe, ce qui fait que mq-deadline s'intègre.

La même logique s'applique lorsqu'un autre élément se charge déjà de la planification à votre place. Les machines virtuelles invitées sur virtio-blk s'appuient sur l'hôte pour planifier les E/S, et les contrôleurs RAID matériels dotés d'un cache à réécriture différée optimisent leur propre ordonnancement. Dans les deux cas, none évite de payer deux fois pour le même travail.

Le profil d’accès est le deuxième facteur. Une base de données effectuant des milliers de lectures aléatoires de 4 Ko par seconde n’a rien de commun avec une tâche d’entraînement diffusant de grands blocs séquentiels à partir d’une baie NVMe, et elles nécessitent des planificateurs différents. Le tableau ci-dessous met en correspondance les charges de travail courantes avec un point de départ.

Il existe une exception qui mérite d'être signalée. Même sur NVMe, si la latence de queue à p99 ou p999 est la métrique qui vous intéresse, comme dans les systèmes financiers, mq-deadline peut être plus performant none en imposant des délais stricts et en empêchant les requêtes occasionnellement retardées.

Modification et réglage des paramètres du planificateur

La commutation des planificateurs et le réglage de leurs paramètres s'effectuent via sysfs, sans qu'un redémarrage ne soit nécessaire pour tester une modification.

Changement du planificateur actif

Vérifiez ce qui est disponible pour un périphérique, la valeur entre parenthèses étant celle qui est active :

cat /sys/block/sda/queue/scheduler

Passez à un autre planificateur pendant l'exécution. Cela prend effet immédiatement mais ne survit pas à un redémarrage :

echo bfq | sudo tee /sys/block/sda/queue/scheduler

Si bfq n'est pas répertorié, chargez d'abord le module :

sudo modprobe bfq

Pour que le choix soit permanent, utilisez une règle udev plutôt que l'ancien elevator= paramètre du noyau, qui ne modifie plus le planificateur sous RHEL 9 et les versions similaires. Cette règle définit mq-deadline pour tous les disques SCSI non rotatifs dans /etc/udev/rules.d/60-io-scheduler.rules:

ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"

Rechargez-la et appliquez-la sans redémarrer :

sudo udevadm control --reload-rules && sudo udevadm trigger

Sur les systèmes basés sur RHEL, les profils TuneD remplissent la même fonction via des profils à l'échelle du système plutôt que par des règles par périphérique.

Paramètres à régler

Chaque planificateur expose ses paramètres réglables sous /sys/block/<device>/queue/iosched/. Pour mq-deadline, les délais sont les principaux leviers. Les bases de données sensibles à la latence sur des SSD SATA tirent profit de délais plus courts :

echo 100 | sudo tee /sys/block/sda/queue/iosched/read_expire
echo 1000 | sudo tee /sys/block/sda/queue/iosched/write_expire

Pour bfq sur les systèmes à haut débit, la désactivation des heuristiques de latence augmente le débit :

echo 0 | sudo tee /sys/block/sda/queue/iosched/low_latency
echo 0 | sudo tee /sys/block/sda/queue/iosched/slice_idle

Pour l'hébergement mutualisé, BFQ s'associe bien avec cgroups v2. L'attribution de io.weight vous permet d'attribuer à un processus de base de données une part d'E/S dix fois supérieure à celle d'une tâche de sauvegarde, par exemple, afin que les tâches en arrière-plan ne prennent pas le pas sur le trafic interactif. Quels que soient les changements que vous apportez, le coût par requête plus élevé de BFQ s'accumule sur les systèmes à forte charge CPU et à haut débit d'E/S, il est donc recommandé d'effectuer des tests de performance avant de valider les modifications.

Vérification des performances après optimisation

Enregistrez toujours une référence avant d'apporter la moindre modification. Sans cela, vous n'avez aucun moyen de savoir si un ajustement a été bénéfique.

fio est l'outil standard pour cela. Il reproduit des modèles de charge de travail spécifiques via la taille des blocs, la profondeur de la file d'attente et les paramètres du moteur d'E/S. Passez toujours --direct=1 afin qu’il contourne le cache de pages et mesure directement le planificateur et le périphérique plutôt que les lectures mises en cache. Adaptez le test à la charge de travail réelle :

Exécutez le même test avec iodepth valeurs comprises entre 1 et 256 pour déterminer le point de saturation du périphérique, c'est-à-dire le seuil à partir duquel les IOPS cessent d'augmenter et la latence atteint des pics. Pour la surveillance en temps réel après une modification, iostat -x 1 génère des rapports sur les métriques qui comptent : r_await et w_await pour la latence d'achèvement en lecture et en écriture, aqu-sz pour la profondeur moyenne de la file d'attente, et %util pour l'utilisation du périphérique. Lorsque %util se situe près de 100 %, c'est le matériel qui constitue la limite et aucun changement de planificateur n'y changera rien.

Pour distinguer le coût logiciel du coût matériel, exécutez blktrace avec btt. Cela permet de décomposer la latence en Q2D, le temps passé dans la file d'attente logicielle, et D2C, le temps que met le périphérique à traiter la requête. Si Q2D domine, le planificateur est votre goulot d'étranglement. Si D2C domine, c'est le matériel.

Une chose à garder à l'esprit lors de la lecture des résultats : le choix du planificateur influence principalement la queue de la distribution de la latence, et non la médiane. Passer de none à mq-deadline sur NVMe peut faire grimper la latence médiane de quelques microsecondes tout en réduisant de moitié les latences p99 et p999. Pour les services destinés aux utilisateurs et soumis à des SLA, ce compromis en vaut presque toujours la peine, c’est pourquoi mesurer la latence de queue, et non le débit moyen, est l’objectif de l’exercice.

Choisir le bon planificateur

Le réglage du planificateur consiste à adapter l'algorithme au matériel et au modèle d'accès, puis à le valider par des mesures. En bref :

• NVMe : utilisez none et laissez le micrologiciel gérer la mise en file d'attente.
• SSD SATA et disques durs avec E/S mixtes : utilisez mq-deadline pour une latence prévisible.
• Hôtes partagés ou multi-locataires : utilisez bfq pour éviter qu'une charge de travail n'épuise les ressources des autres.
• Suivez la latence de queue, pas la médiane : les changements de planificateur apparaissent aux p99 et p999, c'est donc ce qu'il faut mesurer.
• Assurez la persistance : utilisez les règles udev ou TuneD, jamais le paramètre elevator= .

Pour tirer le meilleur parti d'un planificateur, il faut commencer par un matériel capable de suivre le rythme. Si vous avez besoin de serveurs équipés de NVMe conçus pour des charges de travail à haut débit et à faible latence, découvrez les options de VPS de FDC.