{"id":16149,"date":"2025-12-23T11:53:06","date_gmt":"2025-12-23T10:53:06","guid":{"rendered":"https:\/\/webhosting.de\/io-scheduler-linux-noop-mq-deadline-bfq-serverboost\/"},"modified":"2025-12-23T11:53:06","modified_gmt":"2025-12-23T10:53:06","slug":"io-scheduler-linux-noop-mq-deadline-bfq-serverboost","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/io-scheduler-linux-noop-mq-deadline-bfq-serverboost\/","title":{"rendered":"Planificateur d'E\/S Linux : Noop, mq-deadline et BFQ expliqu\u00e9s dans le domaine de l'h\u00e9bergement"},"content":{"rendered":"<p>Le planificateur d'E\/S Linux d\u00e9cide comment le syst\u00e8me trie, hi\u00e9rarchise et envoie les acc\u00e8s en lecture et en \u00e9criture vers les SSD, NVMe et HDD. Dans ce guide, j'explique de mani\u00e8re pratique quand <strong>Noop<\/strong>, <strong>mq-deadline<\/strong> et <strong>BFQ<\/strong> sont le meilleur choix en mati\u00e8re d'h\u00e9bergement \u2013 y compris le r\u00e9glage, les tests et les \u00e9tapes claires \u00e0 suivre.<\/p>\n\n<h2>Points centraux<\/h2>\n\n<ul>\n  <li><strong>Noop<\/strong>: surcharge minimale sur SSD\/NVMe et dans les machines virtuelles<\/li>\n  <li><strong>mq-deadline<\/strong>: latence et d\u00e9bit \u00e9quilibr\u00e9s pour les serveurs<\/li>\n  <li><strong>BFQ<\/strong>: \u00e9quit\u00e9 et r\u00e9activit\u00e9 dans les environnements multi-utilisateurs<\/li>\n  <li><strong>blk-mq<\/strong>: Conception multi-file d'attente pour mat\u00e9riel moderne<\/li>\n  <li><strong>Tuning<\/strong>: Tests par charge de travail au lieu de r\u00e8gles fixes<\/li>\n<\/ul>\n\n<h2>Comment fonctionne le planificateur d'E\/S dans l'h\u00e9bergement Linux<\/h2>\n\n<p>Un planificateur d'E\/S Linux classe les demandes d'E\/S dans des files d'attente, effectue des fusions et d\u00e9cide de la livraison au p\u00e9riph\u00e9rique afin de <strong>Latence<\/strong> et d'augmenter le d\u00e9bit. Les noyaux modernes utilisent blk-mq, c'est-\u00e0-dire Multi-Queue, afin que plusieurs c\u0153urs de processeur puissent d\u00e9clencher des E\/S en parall\u00e8le. Cela convient aux SSD NVMe, qui offrent de nombreuses files d'attente et un parall\u00e9lisme \u00e9lev\u00e9, ce qui r\u00e9duit les files d'attente. Dans l'h\u00e9bergement, des charges mixtes importantes se rencontrent souvent : les serveurs web fournissent de nombreuses petites lectures, les bases de donn\u00e9es g\u00e9n\u00e8rent des \u00e9critures synchronis\u00e9es, les sauvegardes g\u00e9n\u00e8rent des flux. Le planificateur appropri\u00e9 r\u00e9duit les encombrements, maintient des temps de r\u00e9ponse stables et prot\u00e8ge les <strong>Serveur<\/strong>Exp\u00e9rience sous contrainte.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/linux-io-scheduler-hosting-8391.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>blk-mq dans la pratique : none vs. noop et param\u00e8tres par d\u00e9faut du noyau<\/h2>\n\n<p>Depuis le noyau 5.x, la conception multi-file d'attente est la voie standard. Il convient de noter que <strong>none<\/strong> l'\u00e9quivalent \u201e Noop \u201c pour blk-mq, tandis que <strong>noop<\/strong> provient historiquement du chemin d'acc\u00e8s \u00e0 file d'attente unique. Sur les p\u00e9riph\u00e9riques NVMe, seul <code>none<\/code> disponible ; sur SATA\/SAS, on voit souvent <code>mq-deadline<\/code>, en option <code>bfq<\/code> et, selon la distribution, \u00e9galement <code>kyber<\/code>. Les valeurs par d\u00e9faut varient : NVMe d\u00e9marre g\u00e9n\u00e9ralement avec <code>none<\/code>, SCSI\/SATA souvent avec <code>mq-deadline<\/code>. Je v\u00e9rifie donc toujours les options disponibles via <code>cat \/sys\/block\/\/queue\/scheduler<\/code> et je d\u00e9cide pour chaque appareil. O\u00f9 seulement <code>none<\/code> est s\u00e9lectionnable, c'est voulu \u2013 un tri suppl\u00e9mentaire n'apporte pratiquement aucune valeur ajout\u00e9e dans ce cas.<\/p>\n\n<h2>Noop dans l'utilisation des serveurs : quand le minimalisme l'emporte<\/h2>\n\n<p>Noop effectue principalement la fusion de blocs adjacents, mais ne trie pas, ce qui r\u00e9duit consid\u00e9rablement la charge CPU. <strong>faible<\/strong> sur les SSD et NVMe, les contr\u00f4leurs et le micrologiciel prennent en charge l'ordre intelligent, de sorte qu'un tri suppl\u00e9mentaire dans le noyau n'apporte gu\u00e8re d'avantages. Dans les machines virtuelles et les conteneurs, je planifie souvent Noop, car l'hyperviseur planifie de toute fa\u00e7on de mani\u00e8re globale. Sur les disques rotatifs, je renonce \u00e0 Noop, car l'absence de tri augmente les temps de recherche. Si vous souhaitez d\u00e9limiter clairement le contexte mat\u00e9riel, examinez d'abord le type de m\u00e9moire. Il est utile de consulter <a href=\"https:\/\/webhosting.de\/fr\/nvme-ssd-hdd-hebergement-web-comparaison-performances-couts-conseils-serveur-professionnel\/\">NVMe, SSD et HDD<\/a>, avant de lancer le planificateur <strong>d\u00e9terminer<\/strong>.<\/p>\n\n<h2>mq-deadline : d\u00e9lais, ordres et priorit\u00e9s claires<\/h2>\n\n<p>mq-deadline attribue des d\u00e9lais courts aux acc\u00e8s en lecture et fait attendre un peu plus longtemps les acc\u00e8s en \u00e9criture afin de <strong>Temps de r\u00e9ponse<\/strong> Le planificateur trie \u00e9galement les adresses de blocs, ce qui r\u00e9duit les temps de recherche, ce qui est particuli\u00e8rement utile pour les disques durs et les matrices RAID. Dans les h\u00f4tes Web et de bases de donn\u00e9es, mq-deadline offre un bon \u00e9quilibre entre latence et d\u00e9bit. Je l'utilise volontiers lorsque les charges de travail sont mixtes et que les lectures et les \u00e9critures sont en attente en permanence. Pour le r\u00e9glage fin, je v\u00e9rifie la profondeur des requ\u00eates, le comportement de r\u00e9\u00e9criture et le cache du contr\u00f4leur afin que la logique Deadline soit coh\u00e9rente. <strong>saisit<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/linux_io_scheduler_meeting_4273.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>BFQ : \u00e9quit\u00e9 et r\u00e9activit\u00e9 pour de nombreux utilisateurs simultan\u00e9s<\/h2>\n\n<p>BFQ r\u00e9partit la bande passante proportionnellement et attribue des budgets par processus, ce qui est perceptible. <strong>\u00e9quitable<\/strong> fonctionne lorsque de nombreux utilisateurs g\u00e9n\u00e8rent des E\/S en parall\u00e8le. Les t\u00e2ches interactives telles que les shells d'administration, les \u00e9diteurs ou les appels API restent rapides, m\u00eame lorsque des sauvegardes sont en cours d'ex\u00e9cution en arri\u00e8re-plan. Sur les disques durs, BFQ atteint souvent un haut niveau d'efficacit\u00e9, car il exploite les phases s\u00e9quentielles et utilise intelligemment les courtes fen\u00eatres d'inactivit\u00e9. Sur les SSD tr\u00e8s rapides, cela entra\u00eene un l\u00e9ger surco\u00fbt, que je mets en balance avec la r\u00e9activit\u00e9 notable. Ceux qui utilisent Cgroups et ioprio peuvent obtenir des garanties claires avec BFQ et \u00e9viter ainsi les d\u00e9sagr\u00e9ments caus\u00e9s par des voisins bruyants. <strong>\u00e9viter<\/strong>.<\/p>\n\n<h2>QoS au quotidien : ioprio, ionice et Cgroups v2 avec BFQ<\/h2>\n\n<p>Pour des <strong>D\u00e9finition des priorit\u00e9s<\/strong> Je combine BFQ avec des r\u00e8gles de processus et Cgroup. Au niveau du processus, je d\u00e9finis avec <code>ionice<\/code> Classes et priorit\u00e9s : <code>ionice -c1<\/code> (en temps r\u00e9el) pour les lectures critiques en termes de latence, <code>ionice -c2 -n7<\/code> (meilleur effort, faible) pour les sauvegardes ou les ex\u00e9cutions d'index, <code>ionice -c3<\/code> (Idle) pour tout ce qui doit fonctionner uniquement pendant les temps d'inactivit\u00e9. Dans Cgroups v2, j'utilise <code>io.weight<\/code> pour les proportions relatives (par exemple 100 contre 1000) et <code>io.max<\/code> pour les limites strictes, par exemple <code>echo \" 259:0 rbps=50M wbps=20M \" &gt; \/sys\/fs\/cgroup\/\/io.max<\/code>. Avec BFQ, les pond\u00e9rations sont converties de mani\u00e8re tr\u00e8s pr\u00e9cise en parts de bande passante, ce qui est id\u00e9al pour l'h\u00e9bergement mutualis\u00e9 et les h\u00e9bergeurs de conteneurs sur lesquels <strong>\u00c9quit\u00e9<\/strong> est plus important que la puissance brute maximale.<\/p>\n\n<h2>Comparaison pratique : quel choix de mat\u00e9riel convient le mieux ?<\/h2>\n\n<p>Le choix d\u00e9pend fortement du type de m\u00e9moire et de l'architecture de la file d'attente, c'est pourquoi je v\u00e9rifie d'abord <strong>Appareil<\/strong> et contr\u00f4leurs. Les SSD et NVMe b\u00e9n\u00e9ficient g\u00e9n\u00e9ralement de Noop\/none, tandis que les disques durs fonctionnent mieux avec mq-deadline ou BFQ. Dans les configurations RAID, les SAN et les h\u00f4tes polyvalents, je pr\u00e9f\u00e8re souvent mq-deadline, car la logique Deadline et le tri s'harmonisent bien. Les environnements multi-utilisateurs avec de nombreuses sessions interactives gagnent souvent \u00e0 utiliser BFQ. Le tableau suivant r\u00e9sume clairement les points forts et les domaines d'application pertinents. <strong>ensemble<\/strong>:<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>planificateur<\/th>\n      <th>Mat\u00e9riel informatique<\/th>\n      <th>Points forts<\/th>\n      <th>Faiblesses<\/th>\n      <th>Sc\u00e9narios d'h\u00e9bergement<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Noop\/aucun<\/td>\n      <td>SSD, NVMe, VM<\/td>\n      <td>Overhead minimal, fusion propre<\/td>\n      <td>Sans tri sur les disques durs, cela pr\u00e9sente des inconv\u00e9nients<\/td>\n      <td>Serveur Flash, conteneur, contr\u00f4l\u00e9 par hyperviseur<\/td>\n    <\/tr>\n    <tr>\n      <td>mq-deadline<\/td>\n      <td>HDD, RAID, serveur polyvalent<\/td>\n      <td>Priorit\u00e9 de lecture stricte, tri, latence stable<\/td>\n      <td>Plus logique que Noop<\/td>\n      <td>Bases de donn\u00e9es, backends Web, charges mixtes<\/td>\n    <\/tr>\n    <tr>\n      <td>BFQ<\/td>\n      <td>HDD, multi-utilisateurs, h\u00f4tes de type bureau<\/td>\n      <td>\u00c9quit\u00e9, r\u00e9activit\u00e9, bonnes s\u00e9quences<\/td>\n      <td>Un peu plus de surcharge sur les SSD tr\u00e8s rapides<\/td>\n      <td>Services interactifs, h\u00e9bergement mutualis\u00e9, serveur de d\u00e9veloppement<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/linux-io-scheduler-hosting-4397.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Configuration : v\u00e9rifier le planificateur et le d\u00e9finir de mani\u00e8re permanente<\/h2>\n\n<p>Je commence par v\u00e9rifier quel planificateur est actif, par exemple avec <code>cat \/sys\/block\/sdX\/queue\/scheduler<\/code>, et note le <strong>Option<\/strong> entre crochets. Pour changer temporairement, j'\u00e9cris par exemple <code>echo mq-deadline | sudo tee \/sys\/block\/sdX\/queue\/scheduler<\/code>. Pour les param\u00e8tres persistants, j'utilise les r\u00e8gles udev ou les param\u00e8tres du noyau tels que <code>scsi_mod.use_blk_mq=1<\/code> et <code>mq-deadline<\/code> dans la ligne de commande. Pour les p\u00e9riph\u00e9riques NVMe, je v\u00e9rifie les chemins d'acc\u00e8s sous <code>\/sys\/block\/nvme0n1\/queue\/<\/code> et effectuez la s\u00e9lection pour chaque appareil. Important : je documente les modifications afin que la maintenance et la restauration puissent s'effectuer sans conjecture. <strong>r\u00e9ussir<\/strong>.<\/p>\n\n<h2>Persistance et automatisation dans l'exploitation<\/h2>\n\n<p>Au quotidien, je privil\u00e9gie la r\u00e9p\u00e9tabilit\u00e9 \u00e0 l'automatisation. Trois m\u00e9thodes ont fait leurs preuves :<\/p>\n<ul>\n  <li><strong>R\u00e8gles udev<\/strong>: exemple pour tous les disques durs (rotationnel = 1) <code>echo 'ACTION==\"add|change\", KERNEL==\"sd*\", ATTR{queue\/rotational}==\"1\", ATTR{queue\/scheduler}=\"mq-deadline\"' &gt; \/etc\/udev\/rules.d\/60-io-scheduler.rules<\/code>, alors <code>udevadm control --reload-rules &amp;&amp; udevadm trigger<\/code>.<\/li>\n  <li><strong>systemd-tmpfiles<\/strong>: Pour des appareils sp\u00e9cifiques, je d\u00e9finis <code>\/etc\/tmpfiles.d\/blk.conf<\/code> avec des phrases telles que <code>w \/sys\/block\/sdX\/queue\/scheduler - - - - mq-deadline<\/code>, qui \u00e9crivent lors du d\u00e9marrage.<\/li>\n  <li><strong>Gestion de configuration<\/strong>: Dans Ansible\/Salt, je cr\u00e9e des classes d'appareils (NVMe, HDD) et je distribue des param\u00e8tres par d\u00e9faut coh\u00e9rents, accompagn\u00e9s de la documentation et de la restauration.<\/li>\n<\/ul>\n<p>Remarque : <code>ascenseur=<\/code> \u00e9tait le param\u00e8tre du noyau pour l'ancien chemin \u00e0 file d'attente unique. Dans blk-mq, je d\u00e9termine le choix <strong>par appareil<\/strong>. Pour les piles (dm-crypt, LVM, MD), je d\u00e9finis le param\u00e8tre par d\u00e9faut sur le p\u00e9riph\u00e9rique sup\u00e9rieur. Vous trouverez plus d'informations \u00e0 ce sujet ci-dessous.<\/p>\n\n<h2>Charges de travail dans l'h\u00e9bergement : identifier les mod\u00e8les et agir correctement<\/h2>\n\n<p>Je commence par analyser la charge : de nombreuses petites lectures indiquent des interfaces Web, des \u00e9critures synchronis\u00e9es intensives sur des bases de donn\u00e9es et des pipelines de journaux, de grands flux s\u00e9quentiels sur des sauvegardes ou <strong>Archives<\/strong>. Des outils tels que <code>iostat<\/code>, <code>vmstat<\/code> et <code>blktrace<\/code> montrent les files d'attente, les latences et les effets de fusion. En cas de temps d'inactivit\u00e9 CPU notable d\u00fb \u00e0 l'E\/S, je renvoie \u00e0 <a href=\"https:\/\/webhosting.de\/fr\/comprendre-lattente-de-s-resoudre-le-goulot-detranglement-de-la-memoire-optimisation\/\">Comprendre l'attente E\/S<\/a>, pour \u00e9liminer les goulots d'\u00e9tranglement de mani\u00e8re structur\u00e9e. Ensuite, je teste 1 \u00e0 2 candidats planificateurs dans des cr\u00e9neaux horaires identiques. Seuls les r\u00e9sultats des mesures sont d\u00e9terminants, et non l'intuition ou <strong>mythes<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/linux_scheduler_hosting_4827.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Approfondir la pratique de mesure : benchmarks reproductibles<\/h2>\n\n<p>Pour prendre des d\u00e9cisions fiables, j'utilise des <strong>fio<\/strong>-Profils et confirmation par des tests r\u00e9els sur les applications :<\/p>\n<ul>\n  <li><strong>Lectures al\u00e9atoires<\/strong> (Web\/Cache) : <code>fio --name=rr --rw=randread --bs=4k --iodepth=32 --numjobs=4 --runtime=120 --time_based --filename=\/mnt\/testfile --direct=1<\/code><\/li>\n  <li><strong>Mix al\u00e9atoire<\/strong> (DB) : <code>fio --name=randmix --rw=randrw --rwmixread=70 --bs=8k --iodepth=64 --numjobs=8 --runtime=180 --time_based --direct=1<\/code><\/li>\n  <li><strong>S\u00e9quentiel<\/strong> (Sauvegarde) : <code>fio --name=seqw --rw=write --bs=1m --iodepth=128 --numjobs=2 --runtime=120 --time_based --direct=1<\/code><\/li>\n<\/ul>\n<p>En parall\u00e8le, je me connecte <code>iostat -x 1<\/code>, <code>pidstat -d 1<\/code> et notez les latences P95\/P99 \u00e0 partir de <code>fio<\/code>. Pour les diagnostics approfondis, j'utilise <code>blktrace<\/code> ou des outils eBPF tels que <code>biolatency<\/code> . Important : je mesure \u00e0 la m\u00eame heure, avec les m\u00eames fen\u00eatres de charge et les m\u00eames tailles de fichiers. Je minimise les effets du cache avec <code>direct=1<\/code> et des pr\u00e9-conditions propres (par exemple, pr\u00e9-remplissage sur le volume).<\/p>\n\n<h2>Syst\u00e8mes de fichiers et planificateurs d'E\/S : l'interaction est essentielle<\/h2>\n\n<p>Le syst\u00e8me de fichiers influence les caract\u00e9ristiques d'E\/S, c'est pourquoi je v\u00e9rifie tr\u00e8s attentivement son mode journal, la profondeur de la file d'attente et le comportement de synchronisation. <strong>exactement<\/strong>. EXT4 et XFS fonctionnent efficacement avec mq-deadline, tandis que ZFS met beaucoup de choses en m\u00e9moire tampon et les agr\u00e8ge. Sur les h\u00f4tes \u00e9quip\u00e9s de ZFS, j'observe souvent un effet de planificateur moindre, car ZFS forme d\u00e9j\u00e0 la sortie. Pour les comparaisons, j'utilise des options de montage et des charges de travail identiques. Si vous \u00e9valuez les options, vous trouverez dans <a href=\"https:\/\/webhosting.de\/fr\/ext4-xfs-zfs-hebergement-comparaison-des-performances-stockage\/\">EXT4, XFS ou ZFS<\/a> perspectives utiles sur <strong>Stockage<\/strong>-R\u00e9glage.<\/p>\n\n<h2>Writeback, cache et barri\u00e8res : la moiti\u00e9 souvent n\u00e9glig\u00e9e<\/h2>\n\n<p>Les planificateurs ne peuvent fonctionner correctement que dans la mesure o\u00f9 le sous-syst\u00e8me de r\u00e9\u00e9criture le permet. Je v\u00e9rifie donc toujours :<\/p>\n<ul>\n  <li><strong>param\u00e8tre dirty<\/strong>: <code>sysctl vm.dirty_background_bytes<\/code>, <code>vm.dirty_bytes<\/code>, <code>vm.dirty_expire_centisecs<\/code> contr\u00f4ler quand et avec quelle agressivit\u00e9 le noyau \u00e9crit. Pour les bases de donn\u00e9es, je r\u00e9duis souvent les pics de rafales afin de maintenir P99 stable.<\/li>\n  <li><strong>Barri\u00e8res\/Flush<\/strong>: options telles que EXT4 <code>barri\u00e8re<\/code> Je ne sauvegarde les vidages par d\u00e9faut XFS que si le mat\u00e9riel (par exemple BBWC) les prend en charge. \u201e nobarrier \u201c sans protection \u00e9lectrique est <strong>risqu\u00e9<\/strong>.<\/li>\n  <li><strong>Cache d'\u00e9criture du p\u00e9riph\u00e9rique<\/strong>: je v\u00e9rifie les param\u00e8tres du cache d'\u00e9criture du contr\u00f4leur afin que <code>fsync<\/code> atterrisse r\u00e9ellement sur le support et pas seulement dans le cache.<\/li>\n<\/ul>\n<p>En lissant Writeback, vous soulagez le planificateur : les d\u00e9lais restent fiables et BFQ a moins \u00e0 lutter contre les vagues soudaines de flush.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/linux_io_scheduler_4813.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Virtualisation, conteneurs et cloud : qui planifie r\u00e9ellement ?<\/h2>\n\n<p>Dans les VM, l'hyperviseur contr\u00f4le le flux d'E\/S physique, c'est pourquoi je choisis souvent Noop\/none dans l'invit\u00e9 afin d'\u00e9viter les doublons. <strong>logique<\/strong> \u00c0 \u00e9viter. Sur l'h\u00f4te lui-m\u00eame, j'utilise mq-deadline ou BFQ en fonction de l'appareil et de la t\u00e2che. Pour les volumes cloud (par exemple, le stockage en blocs r\u00e9seau), une partie de la planification se fait en arri\u00e8re-plan ; je mesure donc les latences r\u00e9elles au lieu de me fier \u00e0 des hypoth\u00e8ses. Pour les h\u00f4tes de conteneurs avec une charge tr\u00e8s mixte, BFQ offre souvent une meilleure interactivit\u00e9. Dans les clusters batch homog\u00e8nes avec Flash-Only, Noop s'impose, car chaque temps CPU compte et les contr\u00f4leurs sont efficaces. <strong>travaillent<\/strong>.<\/p>\n\n<h2>RAID, LVM, MD et Multipath : o\u00f9 intervient le planificateur<\/h2>\n\n<p>Dans les piles de blocs empil\u00e9s, je place le planificateur au <strong>Appareil haut de gamme<\/strong> car c'est l\u00e0 que se trouvent les files d'attente pertinentes :<\/p>\n<ul>\n  <li><strong>LVM\/dm-crypt<\/strong>: Planificateur sur <code>\/dev\/dm-*<\/code> respectivement <code>\/dev\/mapper\/<\/code> Je laisse g\u00e9n\u00e9ralement les PV physiques sur <code>none<\/code>, afin d'\u00e9viter que la fusion\/le tri ne se produise deux fois.<\/li>\n  <li><strong>MD-RAID<\/strong>: Le <code>\/dev\/mdX<\/code> d\u00e9cider ; en dessous <code>sdX<\/code> Les appareils restent calmes <code>none<\/code>. Le RAID mat\u00e9riel est trait\u00e9 comme un p\u00e9riph\u00e9rique bloc unique.<\/li>\n  <li><strong>multivoie<\/strong>: Sur le mappeur multipath (<code>\/dev\/mapper\/mpatha<\/code>) ; les p\u00e9riph\u00e9riques de chemin d'acc\u00e8s en dessous sur <code>none<\/code>.<\/li>\n<\/ul>\n<p>Important : je s\u00e9pare les tests selon <strong>piscine<\/strong> et niveau de redondance (RAID1\/10 vs RAID5\/6). Les RAID \u00e0 parit\u00e9 sont plus sensibles aux \u00e9critures al\u00e9atoires ; ici, mq-deadline l'emporte souvent gr\u00e2ce \u00e0 des d\u00e9lais de lecture coh\u00e9rents et une sortie ordonn\u00e9e.<\/p>\n\n<h2>Strat\u00e9gies de r\u00e9glage : \u00e9tape par \u00e9tape vers une performance fiable<\/h2>\n\n<p>Je commence par une mesure de base : temps de r\u00e9ponse actuels, d\u00e9bit, 95e\/99e centile et CPU.<strong>Charge<\/strong>. Ensuite, je ne modifie qu'un seul facteur, g\u00e9n\u00e9ralement le planificateur, et je r\u00e9p\u00e8te la m\u00eame charge. Des outils tels que <code>fio<\/code> aident \u00e0 contr\u00f4ler, mais je confirme chaque hypoth\u00e8se \u00e0 l'aide de tests d'application r\u00e9els. Pour les bases de donn\u00e9es, il convient d'utiliser des benchmarks sp\u00e9cifiques qui refl\u00e8tent les transactions et le comportement fsync. Ce n'est que lorsque la mesure est stable que je consigne mon choix et que je le documente. <strong>Pourquoi<\/strong>.<\/p>\n\n<h2>Profondeur de la file d'attente, lecture anticip\u00e9e et affinit\u00e9 CPU<\/h2>\n\n<p>Outre le planificateur, les param\u00e8tres de file d'attente ont une forte influence sur la pratique :<\/p>\n<ul>\n  <li><strong>Profondeur de la file d'attente<\/strong>: <code>\/sys\/block\/\/queue\/nr_requests<\/code> Limite les requ\u00eates en attente par file d'attente mat\u00e9rielle. NVMe supporte une profondeur \u00e9lev\u00e9e (d\u00e9bit \u00e9lev\u00e9), les disques durs b\u00e9n\u00e9ficient d'une profondeur mod\u00e9r\u00e9e (latence plus stable).<\/li>\n  <li><strong>Readahead<\/strong>: <code>\/sys\/block\/\/queue\/read_ahead_kb<\/code> respectivement <code>blockdev --getra\/setra<\/code>. L\u00e9g\u00e8rement plus \u00e9lev\u00e9 pour les charges de travail s\u00e9quentielles, faible pour les charges de travail al\u00e9atoires.<\/li>\n  <li><strong>rq_affinity<\/strong>: Avec <code>\/sys\/block\/\/queue\/rq_affinity<\/code> sur 2, je veille \u00e0 ce que l'ach\u00e8vement des E\/S soit prioritairement effectu\u00e9 sur le c\u0153ur de processeur g\u00e9n\u00e9rateur, ce qui r\u00e9duit les co\u00fbts inter-processeurs.<\/li>\n  <li><strong>rotationnel<\/strong>: Je v\u00e9rifie que les SSD <code>rotationnelle=0<\/code> pour que le noyau n'applique pas d'heuristiques HDD.<\/li>\n  <li><strong>Fusions<\/strong>: <code>\/sys\/block\/\/queue\/nomerges<\/code> Peut r\u00e9duire les fusions (2 = d\u00e9sactiv\u00e9). Utile pour la micro-latence NVMe, mais g\u00e9n\u00e9ralement d\u00e9savantageux pour les disques durs.<\/li>\n  <li><strong>io_poll<\/strong> (NVMe) : le polling peut r\u00e9duire les latences, mais n\u00e9cessite un CPU. Je l'active de mani\u00e8re cibl\u00e9e pour <strong>Faible latence<\/strong>-exigences.<\/li>\n<\/ul>\n\n<h2>Param\u00e8tres de planification d\u00e9taill\u00e9s<\/h2>\n\n<p>Selon le planificateur, des r\u00e9glages pr\u00e9cis utiles sont disponibles :<\/p>\n<ul>\n  <li><strong>mq-deadline<\/strong>: <code>\/sys\/block\/\/queue\/iosched\/read_expire<\/code> (ms, g\u00e9n\u00e9ralement faible), <code>write_expire<\/code> (plus grand), <code>fifo_batch<\/code> (taille du lot), <code>front_merges<\/code> (0\/1). Je consid\u00e8re que <code>read_expire<\/code> bref, pour prot\u00e9ger les lectures P95, et ajuste <code>fifo_batch<\/code> selon l'appareil.<\/li>\n  <li><strong>BFQ<\/strong>: <code>slice_idle<\/code> (temps d'inactivit\u00e9 pour l'utilisation de la s\u00e9quence), <code>faible latence<\/code> (0\/1) pour une interactivit\u00e9 r\u00e9active. Avec <code>bfq.weight<\/code> Dans les cgroups, je contr\u00f4le les parts relatives de mani\u00e8re tr\u00e8s pr\u00e9cise.<\/li>\n  <li><strong>none\/noop<\/strong>: Peu de vis de r\u00e9glage, mais les <strong>Environs<\/strong> (profondeur de la file d'attente, lecture anticip\u00e9e) d\u00e9termine les r\u00e9sultats.<\/li>\n<\/ul>\n<p>Je ne modifie toujours qu'un seul param\u00e8tre et je note rigoureusement chaque modification, afin de pouvoir identifier clairement l'effet produit par chacune d'entre elles.<\/p>\n\n<h2>Les pi\u00e8ges courants et comment je les \u00e9vite<\/h2>\n\n<p>Les pools mixtes compos\u00e9s de disques durs et SSD derri\u00e8re un contr\u00f4leur RAID faussent les tests, c'est pourquoi je s\u00e9pare les mesures par <strong>Groupe<\/strong>. Je n'oublie pas que le planificateur s'applique par p\u00e9riph\u00e9rique de bloc \u2013 je consid\u00e8re les mappeurs LVM et les p\u00e9riph\u00e9riques MD s\u00e9par\u00e9ment. La persistance a tendance \u00e0 dispara\u00eetre : sans r\u00e8gle udev ou param\u00e8tre du noyau, la valeur par d\u00e9faut est r\u00e9tablie apr\u00e8s le red\u00e9marrage. Les cgroups et les priorit\u00e9s d'E\/S restent souvent inutilis\u00e9s, bien qu'ils am\u00e9liorent consid\u00e9rablement l'\u00e9quit\u00e9. Et je v\u00e9rifie toujours la profondeur de la file d'attente, le writeback et les options du syst\u00e8me de fichiers afin que la logique choisie puisse exploiter tout son potentiel. <strong>montre<\/strong>.<\/p>\n\n<h2>D\u00e9pannage : lire les sympt\u00f4mes de mani\u00e8re cibl\u00e9e<\/h2>\n\n<p>Lorsque les valeurs mesur\u00e9es changent, j'interpr\u00e8te les tendances et j'en d\u00e9duis des mesures concr\u00e8tes :<\/p>\n<ul>\n  <li><strong>Latence P99 \u00e9lev\u00e9e lors de nombreuses lectures<\/strong>V\u00e9rifier si les \u00e9critures prennent le pas sur les lectures. Tester avec mq-deadline., <code>read_expire<\/code> r\u00e9duire, lisser la reprise (<code>vm.dirty_*<\/code> adapter).<\/li>\n  <li><strong>100% util sur disque dur, faible d\u00e9bit<\/strong>: Rechercher les dominantes. Essayer BFQ ou mq-deadline, r\u00e9duire Readahead, mod\u00e9rer la profondeur de la file d'attente.<\/li>\n  <li><strong>Bon d\u00e9bit, mais interface utilisateur saccad\u00e9e<\/strong>: l'interactivit\u00e9 en p\u00e2tit. Activer BFQ, services critiques via <code>ionice -c1<\/code> ou privil\u00e9gier les pond\u00e9rations Cgroup.<\/li>\n  <li><strong>Forte variance selon l'heure de la journ\u00e9e<\/strong>: Ressources partag\u00e9es. Isoler avec Cgroups, choisir le planificateur par pool, d\u00e9placer les sauvegardes vers les heures creuses.<\/li>\n  <li><strong>D\u00e9lais d'attente NVMe dans dmesg<\/strong>: Backend ou th\u00e8me du micrologiciel. <code>io_poll<\/code> D\u00e9sactiver \u00e0 titre d'essai, v\u00e9rifier le micrologiciel\/pilote, v\u00e9rifier la redondance du chemin (multipath).<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/linux-io-hosting-9481.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>En bref : des d\u00e9cisions claires pour l'h\u00e9bergement au quotidien<\/h2>\n\n<p>Pour le stockage flash et les invit\u00e9s, j'opte souvent pour <strong>Noop<\/strong>, pour r\u00e9duire les frais g\u00e9n\u00e9raux et laisser les contr\u00f4leurs fonctionner. Dans les serveurs polyvalents \u00e9quip\u00e9s d'un disque dur ou d'un RAID, mq-deadline offre une latence fiable et une grande facilit\u00e9 d'utilisation. Lorsque les utilisateurs actifs sont nombreux et la charge interactive importante, BFQ garantit un partage \u00e9quitable et une r\u00e9activit\u00e9 notable. Avant chaque fixation, je mesure avec des charges de travail r\u00e9elles et j'observe les effets sur P95\/P99. Cela me permet de prendre des d\u00e9cisions compr\u00e9hensibles, de maintenir les syst\u00e8mes \u00e0 flot et de stabiliser la <strong>Serveur<\/strong>-Performance dans les activit\u00e9s quotidiennes.<\/p>","protected":false},"excerpt":{"rendered":"<p>Explication du planificateur d'E\/S Linux : noop, mq-deadline et BFQ pour un h\u00e9bergement optimal. Conseils d'optimisation du stockage pour les performances des serveurs.<\/p>","protected":false},"author":1,"featured_media":16142,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-16149","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"1816","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":null,"_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"I\/O Scheduler Linux","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"16142","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/16149","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/comments?post=16149"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/16149\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/16142"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=16149"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=16149"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=16149"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}