{"id":18553,"date":"2026-03-30T15:05:26","date_gmt":"2026-03-30T13:05:26","guid":{"rendered":"https:\/\/webhosting.de\/linux-scheduler-cfs-alternativen-hosting-kernelperf-boost\/"},"modified":"2026-03-30T15:05:26","modified_gmt":"2026-03-30T13:05:26","slug":"linux-scheduler-cfs-alternatives-hebergement-kernelperf-boost","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/linux-scheduler-cfs-alternativen-hosting-kernelperf-boost\/","title":{"rendered":"Linux Scheduler CFS : fonctionnement et alternatives dans l'h\u00e9bergement de serveurs"},"content":{"rendered":"<p>Le planificateur Linux CFS contr\u00f4le la mani\u00e8re dont les c\u0153urs de serveur allouent leur temps aux processus et influence ainsi directement la latence, le d\u00e9bit et l'\u00e9quit\u00e9 dans l'h\u00e9bergement de serveurs. Dans ce guide, j'explique le fonctionnement, les leviers de r\u00e9glage et les alternatives judicieuses comme ULE, BFS et EEVDF pour <strong>H\u00e9bergement<\/strong> avec <strong>Serveurs web<\/strong>.<\/p>\n\n<h2>Points centraux<\/h2>\n\n<ul>\n  <li><strong>\u00c9quit\u00e9<\/strong> et <strong>vruntime<\/strong> d\u00e9terminer quelle t\u00e2che obtient le CPU.<\/li>\n  <li><strong>Cgroups<\/strong> r\u00e9gissent les quotas et <strong>cpu.shares<\/strong> pour l'isolation des clients.<\/li>\n  <li><strong>R\u00e9glage du noyau<\/strong> sur sched_latency_ns et <strong>Granularit\u00e9<\/strong>.<\/li>\n  <li><strong>Alternatives<\/strong> tels que BFS, ULE, EEVDF pour des <strong>Charges de travail<\/strong>.<\/li>\n  <li><strong>Cabinet m\u00e9dical<\/strong>: Core-Affinity, planificateur d'E\/S et <strong>Tests<\/strong> combiner.<\/li>\n<\/ul>\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\/2026\/03\/linux-server-cfs-9357.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comment CFS travaille au quotidien dans le domaine de l'h\u00e9bergement<\/h2>\n\n<p>Avec le Completely Fair Scheduler, c'est un runtime virtuel qui d\u00e9cide de la prochaine t\u00e2che \u00e0 ex\u00e9cuter, ce qui permet une <strong>\u00e9quitable<\/strong> et pr\u00e9visibles <strong>Attribution<\/strong> est cr\u00e9\u00e9e. Chaque t\u00e2che re\u00e7oit du temps CPU proportionnellement \u00e0 la valeur nice, de sorte qu'une valeur nice faible re\u00e7oit plus de parts. Dans les environnements d'h\u00e9bergement, de nombreuses petites requ\u00eates web, des t\u00e2ches cron et des sauvegardes s\u00e9parent le CPU entre eux, sans qu'un processus n'occupe tout. Les charges de travail interactives telles que les requ\u00eates NGINX b\u00e9n\u00e9ficient de tranches de temps fr\u00e9quentes et courtes, tandis que les t\u00e2ches par lots re\u00e7oivent des blocs plus longs. Ainsi, les temps de r\u00e9ponse restent fiables pour les utilisateurs, m\u00eame si de nombreux sites traitent des requ\u00eates en parall\u00e8le.<\/p>\n\n<p>J'utilise les cgroups pour limiter les clients et les services, car cpu.shares et cpu.max garantissent une r\u00e9partition claire des ressources. <strong>Sommes des parts<\/strong> et dur <strong>Limites<\/strong>. Une valeur par d\u00e9faut de 1024 shares pour \u201cnormal\u201d et 512 pour \u201cmoins important\u201d r\u00e9partit les c\u0153urs de mani\u00e8re compr\u00e9hensible. Avec cpu.max, je d\u00e9finis par exemple 50 ms dans une p\u00e9riode de 100 ms, ce qui correspond effectivement \u00e0 50% de part de CPU. Pour les charges de travail d'h\u00e9bergement avec une charge variable, cette configuration offre des r\u00e9serves planifiables. Les d\u00e9tails du principe sont expliqu\u00e9s de mani\u00e8re compacte sur <a href=\"https:\/\/webhosting.de\/fr\/cpu-scheduling-hosting-distribution-equitable-hebergement-de-serveur-ressources-optimales\/\">r\u00e9partition \u00e9quitable des CPU<\/a>.<\/p>\n\n<h2>La m\u00e9canique du CFS expliqu\u00e9e de mani\u00e8re compr\u00e9hensible<\/h2>\n\n<p>Au c\u0153ur de CFS, toutes les t\u00e2ches pr\u00eates \u00e0 \u00eatre ex\u00e9cut\u00e9es sont g\u00e9r\u00e9es dans une arborescence rouge et noire, tri\u00e9es par <strong>vruntime<\/strong> et avec une efficacit\u00e9 <strong>S\u00e9lection<\/strong> le plus petit temps d'ex\u00e9cution virtuel. Cette t\u00e2che s'ex\u00e9cute ensuite et augmente son vruntime proportionnellement au temps CPU consomm\u00e9 et pond\u00e9r\u00e9 par la valeur nice. Il en r\u00e9sulte un \u00e9quilibre fluide sans files d'attente dures, qui fournit des r\u00e9sultats propres, en particulier pour les charges de travail mixtes. Sur les syst\u00e8mes multic\u0153urs, le planificateur d\u00e9place les t\u00e2ches entre les files d'attente, mais veille \u00e0 la localit\u00e9 du cache via l'affinit\u00e9 du c\u0153ur. CFS combine ainsi la r\u00e9partition de la charge avec le moins de migrations co\u00fbteuses possible.<\/p>\n\n<p>Pour le r\u00e9glage fin, des param\u00e8tres comme sched_latency_ns et sched_min_granularity_ns posent les jalons pour <strong>Latence<\/strong> et <strong>D\u00e9bit<\/strong>. Des valeurs de latence plus faibles favorisent les t\u00e2ches courtes et interactives, des valeurs plus \u00e9lev\u00e9es renforcent les t\u00e2ches par lots. Dans des tests avec des outils comme stress-ng et fio, je v\u00e9rifie l'effet sur les temps de r\u00e9ponse et l'utilisation du CPU. Plus le nombre de t\u00e2ches augmente, plus la charge administrative de l'arbre augmente, ce qui peut se traduire par des latences de pointe. Des quotas et des limites correctement d\u00e9finis permettent toutefois de ma\u00eetriser ces effets dans les environnements d'h\u00e9bergement.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/linux_scheduler_cfs_meeting_4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Points forts de CFS en mati\u00e8re d'h\u00e9bergement de serveurs<\/h2>\n\n<p>La plus grande force r\u00e9side dans la <strong>\u00c9quit\u00e9<\/strong>, Les r\u00e9sultats de l'enqu\u00eate ont \u00e9t\u00e9 <strong>Ressources<\/strong> est distribu\u00e9. Pour les environnements partag\u00e9s, cela signifie qu'aucun client ne supplante durablement les autres, car les quotas et les partages d\u00e9finissent clairement les priorit\u00e9s. Les services interactifs b\u00e9n\u00e9ficient de temps de r\u00e9action rapides, tandis que les sauvegardes peuvent se d\u00e9rouler sans pr\u00e9cipitation. La priorisation via les valeurs nice compl\u00e8te ce tableau et me laisse de la place pour la concertation en fonction du r\u00f4le d'un service. Gr\u00e2ce \u00e0 l'\u00e9quilibrage de la charge sur tous les c\u0153urs, j'utilise bien la puissance de calcul disponible sans donner trop de place aux moments de jeff des diff\u00e9rents threads.<\/p>\n\n<p>En pratique, cette force se r\u00e9v\u00e8le lors des pics du serveur web et de l'arriv\u00e9e de nombreuses requ\u00eates courtes, car CFS attribue de fr\u00e9quents cr\u00e9neaux \u00e0 ces types de t\u00e2ches. Les Cgroups propres aident \u00e0 fixer des limites sup\u00e9rieures strictes par client ou conteneur. Les mesures sur les moyennes et les centiles indiquent des temps de r\u00e9ponse fiables, ce qui s'av\u00e8re payant dans les activit\u00e9s quotidiennes. Cette approche s'av\u00e8re particuli\u00e8rement efficace pour les piles d'applications comportant de nombreux composants. C'est pr\u00e9cis\u00e9ment l\u00e0 que le m\u00e9lange d'\u00e9quit\u00e9 planifiable et de flexibilit\u00e9 suffisante marque des points.<\/p>\n\n<h2>Limites et \u00e9cueils typiques<\/h2>\n\n<p>En pr\u00e9sence d'un nombre extr\u00eamement \u00e9lev\u00e9 de t\u00e2ches simultan\u00e9es, l'overhead des op\u00e9rations en arborescence augmente, ce qui, dans le cas de <strong>Pointes<\/strong> le <strong>Latence<\/strong> peut entra\u00eener. Dans les configurations d'h\u00e9bergement avec de nombreuses requ\u00eates tr\u00e8s courtes, les changements de contexte sont parfois fr\u00e9quents. Un tel comportement \u201cthrash\u201d r\u00e9duit l'efficacit\u00e9 si les valeurs de granularit\u00e9 sont mal choisies. Des tranches de temps moins nombreuses mais plus longues peuvent aider, \u00e0 condition que l'interactivit\u00e9 soit maintenue. CFS est sensible aux quotas erron\u00e9s, c'est pourquoi je v\u00e9rifie syst\u00e9matiquement les limites avec des tests de charge.<\/p>\n\n<p>M\u00eame les charges de travail \u00e0 affinit\u00e9 souffrent lorsque les t\u00e2ches sautent trop souvent entre les c\u0153urs. Un concept d'affinit\u00e9 propre maintient les caches au chaud et r\u00e9duit les co\u00fbts de migration. En outre, j'aime lier les t\u00e2ches de traitement par lots bruyantes \u00e0 leurs propres c\u0153urs, afin que les requ\u00eates web s'ex\u00e9cutent tranquillement sur leurs c\u0153urs. Pour les services critiques en termes de latence, il vaut la peine de d\u00e9finir des valeurs nice basses et une latence finement ajust\u00e9e. Au final, ce qui compte, c'est que les mesures confirment les param\u00e8tres choisis.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/linux-scheduler-cfs-server-7012.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comparaison des alternatives : ULE, BFS et EEVDF<\/h2>\n\n<p>Pour des charges de travail sp\u00e9cifiques, j'\u00e9tudie des alternatives pour <strong>Latence<\/strong> ou <strong>Mise \u00e0 l'\u00e9chelle<\/strong> de mani\u00e8re diff\u00e9rente. ULE utilise des files d'attente plus simples et marque des points avec peu de frais administratifs, BFS donne la priorit\u00e9 \u00e0 la r\u00e9activit\u00e9 et brille avec peu de t\u00e2ches, et EEVDF combine une r\u00e9partition \u00e9quitable avec des d\u00e9lais. EEVDF promet justement des temps d'attente plus courts pour les charges interactives, car l'ordonnanceur tient davantage compte de la \u201cpremi\u00e8re \u00e9ch\u00e9ance autoris\u00e9e\u201d. Pour les tr\u00e8s grands champs de serveurs, ce qui compte en fin de compte, c'est quel m\u00e9lange d'efficacit\u00e9 et de planifiabilit\u00e9 gagne vraiment dans sa propre pile. Un regard structur\u00e9 sur les forces, les faiblesses et les champs d'application aide \u00e0 faire son choix.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>planificateur<\/th>\n      <th>Complexit\u00e9<\/th>\n      <th>Points forts de l'h\u00e9bergement<\/th>\n      <th>Faiblesses<\/th>\n      <th>Convient pour<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>CFS<\/strong><\/td>\n      <td>Haute<\/td>\n      <td>Une distribution \u00e9quitable, <strong>Cgroups<\/strong><\/td>\n      <td>Pointes de latence<\/td>\n      <td>H\u00e9bergement partag\u00e9, charges mixtes<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>ULE<\/strong><\/td>\n      <td>Faible<\/td>\n      <td>Queues simples, faible <strong>Dernier<\/strong><\/td>\n      <td>Moins d'isolation<\/td>\n      <td>VMs, mod\u00e8les de type HPC<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>OFS<\/strong><\/td>\n      <td>Moyens<\/td>\n      <td>Interactivit\u00e9, <strong>Tempo<\/strong><\/td>\n      <td>Faible mise \u00e0 l'\u00e9chelle<\/td>\n      <td>Ordinateurs de bureau, petits serveurs<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>EEVDF<\/strong><\/td>\n      <td>Moyens<\/td>\n      <td>Faible latence, <strong>dates limites<\/strong><\/td>\n      <td>Encore peu de pratique<\/td>\n      <td>Des piles d'h\u00e9bergement modernes<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>R\u00e9glage du noyau : \u00e9tapes pratiques pour CFS<\/h2>\n\n<p>Pour CFS, je commute souvent sched_autogroup_enabled=0 afin qu'aucun groupe implicite ne d\u00e9forme l'image et que les <strong>R\u00e9partition de la charge<\/strong> clair <strong>reste<\/strong>. Avec sched_latency_ns, j'aime commencer \u00e0 20ms, ce qui favorise les services interactifs, et ajuster sched_min_granularity_ns pour dompter les changements de contexte. Les valeurs d\u00e9pendent du profil : de nombreuses requ\u00eates web courtes n\u00e9cessitent d'autres r\u00e9glages fins que les fen\u00eatres de sauvegarde. Je teste les changements en s\u00e9rie et mesure les centiles au lieu de consid\u00e9rer uniquement les moyennes. Cela garantit que non seulement les moyennes sont jolies, mais aussi que les longues files d'attente se r\u00e9duisent.<\/p>\n\n<p>Les personnes qui souhaitent modifier les param\u00e8tres sysctl de mani\u00e8re plus approfondie trouveront une bonne introduction ici : <a href=\"https:\/\/webhosting.de\/fr\/kernel-tuning-linux-sysctl-parameter-serverboost-opti\/\">R\u00e9glage sysctl<\/a>. En outre, je r\u00e8gle la r\u00e9partition des IRQ, le gouverneur du CPU et les profils d'\u00e9nergie afin que le CPU ne bascule pas constamment dans des \u00e9tats d'\u00e9conomie. Pour les piles \u00e0 latence \u00e9lev\u00e9e, j'utilise des gouverneurs de performance, tandis que les pures bo\u00eetes de traitement par lots vivent avec un contr\u00f4le \u00e9quilibr\u00e9. Je s\u00e9pare clairement les phases de test et de production afin de ne pas livrer de surprises. Apr\u00e8s chaque \u00e9tape, je v\u00e9rifie les logs et les m\u00e9triques avant de continuer \u00e0 tourner.<\/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\/2026\/03\/linux_scheduler_cfs_tech_office_5278.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Utiliser judicieusement les cgroups et les quotas<\/h2>\n\n<p>Avec cpu.shares, j'assigne des valeurs relatives <strong>Poids<\/strong> tandis que cpu.max est un <strong>Fronti\u00e8res<\/strong> met en place. Un client avec 512 parts obtient deux fois moins de temps de calcul qu'un client avec 1024 parts, si les deux g\u00e9n\u00e8rent une charge en m\u00eame temps. Avec cpu.max, je limite proprement les pics, par exemple 50 ms en 100 ms. Pour les t\u00e2ches d\u00e9di\u00e9es, cpuset.cpus est utile pour qu'un service utilise des c\u0153urs fixes et que le cache reste chaud. Au total, cela donne une s\u00e9paration r\u00e9siliente entre les clients et les services.<\/p>\n\n<p>Je documente chaque modification et la compare aux niveaux de service que je veux atteindre. Sans valeurs de mesure, les partages conduisent rapidement \u00e0 des interpr\u00e9tations erron\u00e9es, c'est pourquoi j'accompagne toujours les adaptations de tests de charge. Pour les conteneurs, je propose des quotas r\u00e9alistes qui supportent les pics, mais qui ne ralentissent pas l'h\u00f4te. Il reste important de pr\u00e9voir un budget d'erreurs planifiable afin de d\u00e9tecter les pics de latence perceptibles. Si l'on fait cela de mani\u00e8re cons\u00e9quente, on \u00e9vite les surprises aux heures de pointe.<\/p>\n\n<h2>Pratique : serveur web et bases de donn\u00e9es sous CFS<\/h2>\n\n<p>Les serveurs web pilot\u00e9s par des \u00e9v\u00e9nements r\u00e9duisent les changements de contexte et s'harmonisent avec CFS, ce qui permet d'obtenir des r\u00e9sultats constants. <strong>Temps de r\u00e9ponse<\/strong> et meilleure <strong>Mise \u00e0 l'\u00e9chelle<\/strong> est g\u00e9n\u00e9r\u00e9. Dans les tests, je vois que NGINX tient des taux de requ\u00eates plus \u00e9lev\u00e9s avec moins de gigue pour le m\u00eame mat\u00e9riel. Les bases de donn\u00e9es r\u00e9agissent positivement \u00e0 l'affinit\u00e9 de c\u0153ur lorsque les t\u00e2ches d'arri\u00e8re-plan sont tenues \u00e0 l'\u00e9cart des c\u0153urs chauds. Des r\u00e8gles simples aident : Web sur les noyaux A-B, batch sur C-D et DB sur E-F. Ainsi, la pile garde le pipeline propre et les caches chauds.<\/p>\n\n<p>De nombreux petits workers PHP-FPM provoquent trop de commutations en cas de granularit\u00e9 agressive. J'augmente alors la tranche de temps minimale et v\u00e9rifie si les temps de r\u00e9ponse restent stables. En m\u00eame temps, j'\u00e9trangle les logs Chatty pour que les E\/S ne deviennent pas un frein. CFS fournit ici la base, mais le sommet de la performance r\u00e9sulte d'un r\u00e9glage fin de l'ensemble de la pile. Ainsi, tous les rouages s'engr\u00e8nent sans couper le souffle de l'h\u00f4te.<\/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\/2026\/03\/linux_scheduler_server_hosting_8372.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>E\/S m\u00e9moire et ordonnancement CPU : l'interaction<\/h2>\n\n<p>Le planificateur CPU et le planificateur E\/S s'influencent mutuellement, c'est pourquoi une configuration coh\u00e9rente peut avoir des effets sensibles sur les performances. <strong>Avantages<\/strong> \u00e0 l'adresse suivante : <strong>Latence<\/strong> apporte. Pour NVMe, j'utilise g\u00e9n\u00e9ralement Noop ou mq-deadline, tandis que sur les disques durs, mq-deadline sert mieux les longues files d'attente. Si le CPU donne du temps ponctuellement, mais que le chemin d'E\/S se bloque, l'effet global bascule. C'est pourquoi j'examine les planificateurs d'E\/S en parall\u00e8le avec les param\u00e8tres CFS. Je pr\u00e9sente ici un aper\u00e7u de Noop, mq-deadline et BFQ : <a href=\"https:\/\/webhosting.de\/fr\/io-scheduler-linux-noop-mq-deadline-bfq-serverboost\/\">Comparaison des planificateurs d'E\/S<\/a>.<\/p>\n\n<p>Pour les h\u00f4tes de bases de donn\u00e9es, j'adapte les profondeurs de file d'attente et le read-ahead afin que les slots planifi\u00e9s par CFS ne se perdent pas en I\/O bloquantes. Les bo\u00eetes de serveurs web avec de nombreux petits fichiers b\u00e9n\u00e9ficient d'une faible latence dans la pile d'E\/S. Dans les sc\u00e9narios de virtualisation, je mise sur des planificateurs coh\u00e9rents sur l'h\u00f4te et l'invit\u00e9 afin d'\u00e9viter les patterns impr\u00e9dictibles. Ainsi, le planificateur de l'unit\u00e9 centrale joue avec le sous-syst\u00e8me de stockage. Au final, ce qui compte, c'est la coh\u00e9rence de la cha\u00eene, de la demande \u00e0 la r\u00e9ponse.<\/p>\n\n<h2>\u00c9quilibrage SMP, affinit\u00e9 de c\u0153ur et NUMA<\/h2>\n\n<p>Je dirige les threads vers des noyaux fixes pour que <strong>Caches<\/strong> chaud et co\u00fbts de migration <strong>petit<\/strong> resteront en place. Pour les h\u00f4tes NUMA, j'\u00e9pingle la m\u00e9moire et le CPU ensemble, car les acc\u00e8s m\u00e9moire distants augmentent la latence. CFS \u00e9quilibre la charge entre les files d'attente, mais des r\u00e8gles d'affinit\u00e9 conscientes permettent souvent d'obtenir davantage. Les services avec un acc\u00e8s fr\u00e9quent au cache b\u00e9n\u00e9ficient de groupes de base stables. Les t\u00e2ches par lots peuvent se d\u00e9placer \u00e0 condition qu'elles ne perturbent pas les noyaux chauds.<\/p>\n\n<p>Dans la pratique, je d\u00e9finis les options cpuset.cpus et numactl, puis je teste les temps de r\u00e9ponse et les taux d'\u00e9chec du processeur. Moins il y a de migrations inutiles, meilleur est le temps de r\u00e9ponse. J'\u00e9value \u00e9galement la r\u00e9partition des interruptions afin d'\u00e9viter que les pics d'IRQ ne bloquent un noyau. J'obtiens ainsi une cadence calme des threads importants. Ce calme se r\u00e9percute sur les performances globales de la pile.<\/p>\n\n<h2>Group Scheduling : nice, pond\u00e9ration et hi\u00e9rarchies<\/h2>\n\n<p>Une pierre d'achoppement fr\u00e9quente dans l'h\u00e9bergement est la <strong>Interaction<\/strong> entre <strong>sympa<\/strong>-priorit\u00e9 et <strong>Poids du Cgroup<\/strong>. CFS r\u00e9partit d'abord \u00e9quitablement entre les groupes, puis au sein du groupe entre les t\u00e2ches. Cela signifie qu'un processus avec nice -5 peut quand m\u00eame recevoir moins de CPU qu'un autre avec nice 0 si son groupe (client\/conteneur) porte un poids plus faible. Pour obtenir des r\u00e9sultats coh\u00e9rents, je commence donc par d\u00e9finir les <em>Poids des groupes<\/em> et n'utilise nice que pour la correction fine au sein d'un service.<\/p>\n\n<p>En pratique, je travaille avec quelques niveaux clairs (par exemple 512\/1024\/2048 shares pour \u201clow\/normal\/high\u201d) et je documente quels services fonctionnent dans quel groupe. Ainsi, la <strong>\u00c9quit\u00e9<\/strong> compr\u00e9hensible dans la hi\u00e9rarchie. Ceux qui travaillent beaucoup avec des processus \u00e0 courte dur\u00e9e de vie (par exemple des jobs CGI\/CLI) profitent en outre de <strong>bas\u00e9 sur cgroup<\/strong> Contr\u00f4le, car sinon les t\u00e2ches volatiles passent involontairement le corset du groupe. Je v\u00e9rifie r\u00e9guli\u00e8rement \u00e0 l'aide de m\u00e9triques de temps d'ex\u00e9cution si la r\u00e9partition interne correspond encore au profil de charge.<\/p>\n\n<h2>Conteneurs et orchestration : requ\u00eates, limites et throttling<\/h2>\n\n<p>Dans les environnements de conteneurs, une \u201crequ\u00eate\u201d mappe typiquement sur <strong>poids relatif<\/strong> (shares\/weight), une \u201climite\u201d sur le <strong>Quota<\/strong> (cpu.max). L'interaction d\u00e9termine <strong>Throttling<\/strong>Si le quota est trop serr\u00e9, l'unit\u00e9 centrale du conteneur est frein\u00e9e pendant la p\u00e9riode - ce qui se voit aux pics de latence p95\/p99. Je maintiens donc les quotas de mani\u00e8re \u00e0 ce que les bursts normaux tiennent dans la p\u00e9riode et que les services soient rarement s\u00e9v\u00e8rement limit\u00e9s. Lorsque cela est possible, j'utilise une <em>rafale<\/em>-r\u00e9serve (par exemple cpu.max.burst) pour amortir les pics courts sans distorsion.<\/p>\n\n<p>Il est important de ne pas fixer des requ\u00eates trop basses : En cas de concurrence, des poids trop faibles font que les services interactifs sont rel\u00e9gu\u00e9s derri\u00e8re le bruit de fond. Je calibre les requ\u00eates \u00e0 l'aide de la charge de base mesur\u00e9e et assure des limites de telle sorte que <strong>Budgets d'erreurs<\/strong> \u00eatre maintenus en p\u00e9riode de pointe. Pour les n\u0153uds multi-locataires, je pr\u00e9vois en outre des noyaux tampons pour \u00e9viter que les pics de charge de certains conteneurs ne se r\u00e9percutent sur les voisins.<\/p>\n\n<h2>M\u00e9thodes de mesure et d\u00e9pannage dans le contexte de l'ordonnanceur<\/h2>\n\n<p>Je n'\u00e9value jamais le tuning CFS \u00e0 l'aveugle, mais je le mesure de mani\u00e8re cibl\u00e9e. Pour avoir une vue d'ensemble, j'utilise<\/p>\n<ul>\n  <li><strong>Longueur de la runqueue<\/strong> par CPU (charge vs. noyaux actifs),<\/li>\n  <li><strong>Changement de contexte<\/strong> par seconde et le nombre de threads,<\/li>\n  <li><strong>Sceau CPU<\/strong> et <strong>SoftIRQ<\/strong>-parts,<\/li>\n  <li><strong>Percentile<\/strong> de temps de r\u00e9ponse (p50\/p95\/p99),<\/li>\n  <li>Distribution de <strong>vruntime<\/strong> ou des latences d'ordonnancement.<\/li>\n<\/ul>\n<p>Si des pics de latence surviennent, je cherche d'abord <strong>Throttling<\/strong> (quota \u00e9puis\u00e9), puis vers <strong>Migrations<\/strong> (froid de cache) et enfin apr\u00e8s <strong>Blocages d'E\/S<\/strong> (profondeur de la file d'attente, saturation du stockage). Je regarde les mod\u00e8les de r\u00e9veil : des r\u00e9veils fr\u00e9quents et brefs de nombreux workers indiquent une granularit\u00e9 trop fine ou des I\/O de chatty. Une proportion \u00e9lev\u00e9e de ksoftirqd sur un noyau indique des files d'attente IRQ \u00e0 chaud - dans ce cas, je distribue des IRQ et j'active RPS\/XPS pour que la charge du r\u00e9seau soit plus largement r\u00e9partie.<\/p>\n\n<h2>Classes en temps r\u00e9el, pr\u00e9emption et contr\u00f4le des ticks<\/h2>\n\n<p>Outre CFS, il existe les classes temps r\u00e9el <strong>SCHED_FIFO\/RR<\/strong>. Ils surchargent CFS : un thread RT mal configur\u00e9 peut litt\u00e9ralement couper l'herbe sous le pied du syst\u00e8me. C'est pourquoi je n'attribue des RT-Prio que de mani\u00e8re tr\u00e8s cibl\u00e9e (par ex. pour l'audio\/la t\u00e9l\u00e9m\u00e9trie) et je d\u00e9finis des watchdogs clairs. Pour l'h\u00e9bergement, il suffit g\u00e9n\u00e9ralement de CFS avec des poids propres.<\/p>\n\n<p>\u00c0 l'adresse suivante : <strong>Pr\u00e9emption<\/strong>Le choix du mod\u00e8le de pr\u00e9emption (par ex. \u201cvoluntary\u201d vs \u201cfull\/dynamic preempt\u201d) d\u00e9place le rapport latence\/d\u00e9bit. Je pr\u00e9f\u00e8re plus de pr\u00e9emption pour les piles web, moins pour les h\u00f4tes purement batch. Optimisation des ticks (<em>nohz<\/em>-) peuvent r\u00e9duire la gigue, mais doivent \u00eatre utilis\u00e9s avec pr\u00e9caution. Sur des noyaux isol\u00e9s, je combine parfois <em>nohz_full<\/em> et Affinity, afin que les hot-threads fonctionnent le moins possible - il est important que la charge du syst\u00e8me et de l'IRQ ne se d\u00e9place alors pas par inadvertance sur ces c\u0153urs.<\/p>\n\n<h2>Virtualisation : KVM, vCPU-Pinning et Steal-Time<\/h2>\n\n<p>Dans un environnement d'hyperviseur, le planificateur h\u00f4te d\u00e9termine quand <strong>vCPU<\/strong> peuvent fonctionner. Cr\u00e9er des surr\u00e9servations <strong>Steal-Time<\/strong> dans les invit\u00e9s, qui agit comme une \u201clatence invisible\u201d. Pour les tenants critiques en termes de latence, j'\u00e9pingle des vCPU sur des c\u0153urs physiques et je maintiens l'overcommit \u00e0 un niveau mod\u00e9r\u00e9. En outre, je s\u00e9pare les threads de l'\u00e9mulateur (threads IO, vhost) des c\u0153urs chauds des invit\u00e9s afin qu'ils ne se g\u00eanent pas mutuellement.<\/p>\n\n<p>J'\u00e9vite le double \u00e9tranglement : si l'invit\u00e9 utilise d\u00e9j\u00e0 cpu.max, je ne mets pas de quotas durs suppl\u00e9mentaires sur la m\u00eame charge de travail sur l'h\u00f4te. Le contr\u00f4le de la fr\u00e9quence reste la t\u00e2che de l'h\u00f4te ; les invit\u00e9s en profitent indirectement si le host-governor s'adapte proprement \u00e0 la charge de travail r\u00e9elle. Pour des latences r\u00e9guli\u00e8res, je consid\u00e8re que la stabilit\u00e9 au-del\u00e0 des simples runs \u00e0 fr\u00e9quence maximale est plus importante que les GHz de pointe sur le papier.<\/p>\n\n<h2>AutoNUMA, localisation de la m\u00e9moire et THP<\/h2>\n\n<p>Le NUMA peut \u00eatre un gain ou un pi\u00e8ge de performance. <strong>AutoNUMA<\/strong> aide souvent, mais peut g\u00e9n\u00e9rer des surcharges suppl\u00e9mentaires en cas de forte migration des threads. Dans les piles d'h\u00e9bergement avec des limites de service claires, j'\u00e9pingle l'unit\u00e9 centrale et le processeur. <strong>M\u00e9moire<\/strong> (<em>cpuset.cpus<\/em> et <em>cpuset.mems<\/em>) en commun. Ainsi, les donn\u00e9es \u00e0 chaud restent locales et CFS doit compenser moins de migrations.<\/p>\n\n<p>Grandes pages (<strong>THP<\/strong>) abaissent TLB-Pressure, mais ne conviennent pas \u00e0 tous les profils. Pour les bases de donn\u00e9es, \u201cmadvise\u201d peut \u00eatre plus judicieux qu'un \u201calways\u201d g\u00e9n\u00e9ralis\u00e9. Les page-faults bloquants affectent durement la latence interactive ; je planifie donc les tampons (cache de page, tampon partag\u00e9) de mani\u00e8re \u00e0 ce que les slots CFS soient utilis\u00e9s de mani\u00e8re productive et n'attendent pas des \u00e9v\u00e9nements I\/O ou MMU. Cela peut \u00eatre mesur\u00e9 par les taux de page par d\u00e9faut et les courbes d'erreur des caches.<\/p>\n\n<h2>Chemin d'acc\u00e8s au r\u00e9seau : contr\u00f4le IRQ, RPS\/XPS et Busy-Polling<\/h2>\n\n<p>De nombreuses charges de travail web sont domin\u00e9es par des NIC. Je distribue <strong>IRQ<\/strong>-de la carte r\u00e9seau sur plusieurs c\u0153urs et les maintenir en place. <em>affin<\/em> vers les fils de discussion des travailleurs, afin que les r\u00e9veils restent locaux. <strong>RPS\/XPS<\/strong> aide \u00e0 r\u00e9soudre les hotspots mous lorsque des queues RX\/TX individuelles portent une charge trop importante. Si ksoftirqd s'\u00e9chauffe visiblement, cela indique que les softIRQs d\u00e9bordent - j'\u00e9galise alors les flux et augmente les param\u00e8tres budg\u00e9taires si n\u00e9cessaire, sans perdre l'\u00e9quit\u00e9.<\/p>\n\n<p>Le busy polling optionnel peut \u00eatre utile dans des configurations \u00e0 faible latence tr\u00e8s particuli\u00e8res, mais il co\u00fbte du temps de CPU. Je l'utilise rarement et seulement si je peux prouver par des mesures que p99 baisse de mani\u00e8re significative sans stresser l'h\u00f4te dans son ensemble. En g\u00e9n\u00e9ral, une affinit\u00e9 d'IRQ propre, des Cgroups et une granularit\u00e9 CFS fournissent un meilleur rapport co\u00fbt\/b\u00e9n\u00e9fice.<\/p>\n\n<h2>Perspectives d'avenir : Du CFS \u00e0 l'EEVDF et aux approches Userspace<\/h2>\n\n<p>L'EEVDF ajoute des dates limites \u00e0 la distribution \u00e9quitable, ce qui est sensible <strong>plus court<\/strong> et plus planifiable <strong>R\u00e9ponses<\/strong> promet de faire. C'est justement sous des objectifs de latence interactifs que cela peut faire pencher la balance. Je surveille de pr\u00e8s les versions du noyau et teste EEVDF s\u00e9par\u00e9ment avant de changer. Parall\u00e8lement, l'ordonnancement de l'espace utilisateur via le mod\u00e8le eBPF prend de l'ampleur et peut permettre un contr\u00f4le suppl\u00e9mentaire en fonction de la charge de travail. Pour les infrastructures d'h\u00e9bergement, CFS reste pertinent, mais EEVDF s'\u00e9tablira rapidement.<\/p>\n\n<p>Il reste important de suivre un chemin de migration clair : tests, d\u00e9ploiement sur des h\u00f4tes s\u00e9lectionn\u00e9s, puis extension. Ce n'est qu'ainsi que les centiles et les taux d'erreur restent contr\u00f4lables. Je garde les benchmarks proches de la r\u00e9alit\u00e9, y compris les phases de burst et les backends lents. Ce n'est qu'ensuite que j'interviens dans des environnements r\u00e9els. C'est ainsi que l'on peut progresser sans mauvaises surprises.<\/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\/2026\/03\/linux-scheduler-hosting-4783.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>En bref<\/h2>\n\n<p>Le planificateur Linux CFS fournit une distribution \u00e9quitable, des int\u00e9grations solides et de bonnes <strong>Contr\u00f4le<\/strong> via <strong>Cgroups<\/strong>. Avec des param\u00e8tres sysctl adapt\u00e9s, une affinit\u00e9 propre et des quotas r\u00e9alistes, je maintiens les latences \u00e0 un niveau faible et le d\u00e9bit \u00e0 un niveau \u00e9lev\u00e9. Pour les mod\u00e8les sp\u00e9ciaux, ULE, BFS ou EEVDF offrent des leviers suppl\u00e9mentaires. Je mesure, compare et d\u00e9ploie les changements par \u00e9tapes afin de limiter les risques. Ainsi, l'h\u00e9bergement reste pr\u00e9visible - et la performance l\u00e0 o\u00f9 elle doit \u00eatre.<\/p>","protected":false},"excerpt":{"rendered":"<p>Linux Scheduler CFS expliqu\u00e9 : fonctionnement, cpu scheduling server et alternatives comme EEVDF. Tuning du noyau pour une performance optimale de l'h\u00e9bergement.<\/p>","protected":false},"author":1,"featured_media":18546,"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-18553","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":"524","_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":"1","_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":"Linux Scheduler CFS","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":"18546","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/18553","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=18553"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/18553\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/18546"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=18553"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=18553"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=18553"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}