{"id":20578,"date":"2026-08-12T13:59:33","date_gmt":"2026-08-12T11:59:33","guid":{"rendered":"https:\/\/webhosting.de\/cfs-scheduler-fair-scheduling-hosting\/"},"modified":"2026-08-12T13:59:33","modified_gmt":"2026-08-12T11:59:33","slug":"cfs-scheduler-planification-equitable-hebergement","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/cfs-scheduler-fair-scheduling-hosting\/","title":{"rendered":"Le planificateur CFS du noyau : comprendre la planification \u00e9quitable sur les serveurs d'h\u00e9bergement"},"content":{"rendered":"<p>Je vais vous expliquer comment le <strong>CFS<\/strong> Le planificateur r\u00e9partit \u00e9quitablement le temps CPU sur les serveurs d'h\u00e9bergement et permet de pr\u00e9voir les temps de r\u00e9ponse. Je montre concr\u00e8tement comment <strong>vruntime<\/strong>, comment les priorit\u00e9s et les limites du syst\u00e8me interagissent, et quels sont les leviers efficaces dans les configurations productives.<\/p>\n\n<h2>Points centraux<\/h2>\n\n<p>Pour vous donner un aper\u00e7u clair, je vais r\u00e9sumer les aspects les plus importants avant d'entrer plus en d\u00e9tail dans le sujet. Le <strong>Enti\u00e8rement<\/strong> Fair Scheduler r\u00e9partit \u00e9quitablement le temps de calcul et hi\u00e9rarchise les t\u00e2ches en fonction des besoins. Sur les serveurs d'h\u00e9bergement, il influe sur la latence, le d\u00e9bit et la perception de stabilit\u00e9. J'\u00e9value les param\u00e8tres de r\u00e9glage pratiques, les charges de travail typiques et les limites raisonnables. Je montre \u00e9galement comment je combine les Cgroups, le quota CPU et l'affinit\u00e9. Cela me permet de comprendre les causes des temps d'attente et de r\u00e9agir de mani\u00e8re cibl\u00e9e \u00e0 <strong>Changement de contexte<\/strong>.<\/p>\n<p>Les points suivants vous aideront \u00e0 vous y retrouver rapidement :<\/p>\n<ul>\n  <li><strong>\u00c9quit\u00e9<\/strong> Avant les performances de pointe : une r\u00e9partition \u00e9quitable de la charge du processeur plut\u00f4t qu'une performance individuelle maximale.<\/li>\n  <li><strong>vruntime<\/strong> d\u00e9termine l'ordre d'ex\u00e9cution : les t\u00e2ches prioritaires sont trait\u00e9es en premier.<\/li>\n  <li><strong>Cgroups<\/strong> Budgets limit\u00e9s : les services partagent les ressources de mani\u00e8re contr\u00f4l\u00e9e.<\/li>\n  <li><strong>Latence<\/strong> et granularit\u00e9 : r\u00e9glage pr\u00e9cis pour une r\u00e9activit\u00e9 et une efficacit\u00e9 optimales.<\/li>\n  <li><strong>Priorit\u00e9<\/strong> et nice : la pond\u00e9ration d\u00e9termine l'ordre d'ex\u00e9cution.<\/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\/08\/serverraum-fair-scheduling-8247.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comment CFS assure une r\u00e9partition \u00e9quitable : vruntime, pond\u00e9ration et arbre rouge-noir<\/h2>\n\n<p>Derri\u00e8re cette \u00e9quit\u00e9 se cache la <strong>vruntime<\/strong>, c'est-\u00e0-dire un temps d'ex\u00e9cution virtuel qui enregistre la consommation de chaque t\u00e2che de mani\u00e8re pond\u00e9r\u00e9e. Chaque t\u00e2che accumule du \u201e vruntime \u201c lorsqu'elle s'ex\u00e9cute, et celle qui en a accumul\u00e9 le moins est ex\u00e9cut\u00e9e en priorit\u00e9. Le noyau place les t\u00e2ches ex\u00e9cutables dans un arbre rouge-noir et identifie ainsi rapidement la t\u00e2che pr\u00e9sentant le plus faible \u00ab retard \u00bb. Cela me permet d\u2019\u00e9conomiser des tranches de temps fixes et de r\u00e9duire la charge administrative dans le chemin normal. Il reste important que la <strong>pond\u00e9ration<\/strong>, que je modifie \u00e0 l'aide de valeurs \u00ab nice \u00bb afin d'affiner l'ordre de priorit\u00e9.<\/p>\n\n<p>Sur les syst\u00e8mes multic\u0153urs, CFS r\u00e9partit les t\u00e2ches par file d'attente d'ex\u00e9cution du processeur et assure l'\u00e9quilibrage entre les c\u0153urs. Je suis ainsi l'influence de l'affinit\u00e9 et de la topologie NUMA sur les temps d'ex\u00e9cution. Lorsque les threads restent sur un m\u00eame c\u0153ur, ils r\u00e9duisent les \u00e9checs de cache et perdent moins de temps en migration. Si je change trop souvent de c\u0153ur, les co\u00fbts li\u00e9s aux changements de contexte et aux caches augmentent. Une attribution judicieuse des c\u0153urs apporte ici des gains notables <strong>Accents<\/strong>.<\/p>\n\n<h2>\u00c9quit\u00e9 ou performances sur les serveurs d'h\u00e9bergement<\/h2>\n\n<p>Sur les h\u00f4tes tr\u00e8s charg\u00e9s, les serveurs Web, les bases de donn\u00e9es et les t\u00e2ches de fond se disputent les m\u00eames c\u0153urs, ce qui met l'\u00e9quit\u00e9 au premier plan. Le CFS assure une r\u00e9partition \u00e9quitable, mais peut, en pr\u00e9sence d'un grand nombre de t\u00e2ches actives, entra\u00eener des <strong>Changement de contexte<\/strong> g\u00e9n\u00e9rer. Si le nombre de processus actifs augmente fortement, la charge administrative s'alourdit de mani\u00e8re significative. Je veille donc \u00e0 maintenir un niveau de parall\u00e9lisme r\u00e9aliste et \u00e0 limiter le nombre de threads en fonction du profil d'E\/S ou du profil CPU. Si vous souhaitez \u00e9valuer des alternatives et des compl\u00e9ments, vous trouverez des informations compl\u00e9mentaires \u00e0 l'adresse suivante : <a href=\"https:\/\/webhosting.de\/fr\/linux-scheduler-cfs-alternatives-hebergement-kernelperf-boost\/\">Alternatives au CFS<\/a>, afin de replacer les d\u00e9cisions dans leur contexte.<\/p>\n\n<p>Une r\u00e9partition \u00e9quitable ne signifie pas une r\u00e9partition aveugl\u00e9ment uniforme. En p\u00e9riode de pointe, les services critiques doivent r\u00e9agir de mani\u00e8re plus fiable que les t\u00e2ches en arri\u00e8re-plan. C'est pr\u00e9cis\u00e9ment pour cela que j'utilise des priorit\u00e9s, des quotas et des groupes de services. Ainsi, la r\u00e9action de la <strong>API<\/strong> en douceur, tandis que les charges de travail par lots continuent de s'ex\u00e9cuter \u2013 mais \u00e0 un rythme r\u00e9duit. C'est cet \u00e9quilibre qui rend les h\u00f4tes productifs <strong>constant<\/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\/2026\/08\/meeting_scheduler_server_8972.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Interaction entre les cgroups, le quota CPU et l'affinit\u00e9<\/h2>\n\n<p>Je regroupe les services par client, conteneur ou r\u00f4le dans <strong>Cgroups<\/strong>, afin que chaque groupe dispose d'un budget bien d\u00e9fini. Gr\u00e2ce aux quotas CPU et aux parts CPU, je fixe des limites strictes ou des pond\u00e9rations relatives. J'\u00e9vite ainsi qu'un voisin bruyant ne sature la machine. De plus, si n\u00e9cessaire, j'affecte les threads \u00e0 des c\u0153urs via l'affinit\u00e9 afin de mieux exploiter les caches. Une bonne introduction \u00e0 <a href=\"https:\/\/webhosting.de\/fr\/server-scheduling-policies-equite-performance-hosting-optimisation\/\">Politiques de planification<\/a> aide \u00e0 structurer clairement les strat\u00e9gies.<\/p>\n\n<p>Pour les piles web, je s\u00e9pare le front-end, les workers PHP et la base de donn\u00e9es en groupes avec des parts de ressources adapt\u00e9es. Les syst\u00e8mes de cache tels que Redis ou Memcached disposent d\u2019une puissance CPU suffisante pour absorber les pics de charge de mani\u00e8re optimale. Les sauvegardes et la compression s\u2019ex\u00e9cutent en arri\u00e8re-plan avec des parts de ressources plus faibles. Sur les n\u0153uds pr\u00e9sentant une charge h\u00e9t\u00e9rog\u00e8ne, j\u2019applique des quotas par client afin que chacun dispose d\u2019un temps de calcul pr\u00e9visible. Cette clart\u00e9 facilite <strong>Planification des capacit\u00e9s<\/strong> et limite les surprises.<\/p>\n\n<h2>Param\u00e8tres cl\u00e9s du noyau : latence et granularit\u00e9<\/h2>\n\n<p>Lors du r\u00e9glage fin, je me concentre surtout sur les param\u00e8tres li\u00e9s \u00e0 <strong>Latence<\/strong> et la granularit\u00e9. Elles d\u00e9terminent la fr\u00e9quence \u00e0 laquelle le CFS change et la taille des tranches de temps effectives. Des valeurs de latence plus faibles am\u00e9liorent la r\u00e9activit\u00e9, mais augmentent la surcharge. Des valeurs plus \u00e9lev\u00e9es permettent de gagner du temps de gestion, mais peuvent allonger la dur\u00e9e des r\u00e9ponses individuelles. Je commence par tester diff\u00e9rents profils, je mesure et je valide les r\u00e9sultats en fonction des pics de charge avant de planifier d\u2019autres \u00e9tapes.<\/p>\n\n<p>Le tableau suivant pr\u00e9sente les commutateurs cl\u00e9s, leurs effets et les recommandations types pour les environnements d'h\u00e9bergement. Les valeurs indiqu\u00e9es sont des orientations, et non des r\u00e8gles absolues. Je v\u00e9rifie toujours les modifications \u00e0 l'aide de tests de charge et de la surveillance. Chaque plateforme r\u00e9agit de mani\u00e8re l\u00e9g\u00e8rement diff\u00e9rente, surtout lorsqu\u2019il y a un grand nombre de conteneurs et de machines virtuelles. C\u2019est pr\u00e9cis\u00e9ment pour cette raison que je documente m\u00e9ticuleusement les ajustements et que je les d\u00e9ploie progressivement afin de <strong>Risques<\/strong> de r\u00e9duire les co\u00fbts.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Param\u00e8tres<\/th>\n      <th>Effet<\/th>\n      <th>Remarque concernant l'h\u00e9bergement<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>kernel.sched_latency_ns<\/td>\n      <td>D\u00e9finit la dur\u00e9e cible d'un cycle complet pour toutes les t\u00e2ches<\/td>\n      <td>Raccourcir les petites valeurs <strong>r\u00e9action<\/strong>, augmentent les co\u00fbts de planification<\/td>\n    <\/tr>\n    <tr>\n      <td>kernel.sched_min_granularity_ns<\/td>\n      <td>Dur\u00e9e minimale par t\u00e2che dans les limites de la latence<\/td>\n      <td>L\u00e9g\u00e8rement plus important pour les t\u00e2ches sollicitant fortement le processeur, l\u00e9g\u00e8rement moins important pour le Web-Mix<\/td>\n    <\/tr>\n    <tr>\n      <td>kernel.sched_wakeup_granularity_ns<\/td>\n      <td>Seuil \u00e0 partir duquel les t\u00e2ches en cours de r\u00e9veil ont la priorit\u00e9<\/td>\n      <td>Une valeur plus \u00e9lev\u00e9e r\u00e9duit la fr\u00e9quence de pr\u00e9emption, ce qui est efficace contre le thrash<\/td>\n    <\/tr>\n    <tr>\n      <td>kernel.sched_migration_cost_ns<\/td>\n      <td>Co\u00fbt de la migration entre noyaux<\/td>\n      <td>L'augmentation freine la migration et favorise la mise en cache\u2011<strong>R\u00e9sultats<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>kernel.sched_cfs_bandwidth_slice_us<\/td>\n      <td>P\u00e9riode de temps pour le contr\u00f4le de la bande passante CFS via un quota<\/td>\n      <td>S'adapter \u00e0 la charge de travail et \u00e0 la fr\u00e9quence d'attribution des quotas<\/td>\n    <\/tr>\n    <tr>\n      <td>kernel.sched_autogroup_enabled<\/td>\n      <td>Regroupe automatiquement les t\u00e2ches interactives<\/td>\n      <td>Tester de mani\u00e8re cibl\u00e9e sur les serveurs ; l'effet d\u00e9pend de la charge<\/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\/2026\/08\/kernel-scheduler-cfs-hosting-7481.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Claser correctement les types de charges de travail<\/h2>\n\n<p>Je distingue les op\u00e9rations gourmandes en ressources CPU, celles li\u00e9es \u00e0 la m\u00e9moire et celles domin\u00e9es par les E\/S <strong>Charges de travail<\/strong>. Le CFS excelle dans les t\u00e2ches serveur mixtes et les charges de travail CPU classiques. Dans les sc\u00e9narios gourmands en m\u00e9moire, c'est souvent la bande passante ou la latence du syst\u00e8me de m\u00e9moire qui constitue le goulot d'\u00e9tranglement, et non le planificateur. Il est alors plus utile de pr\u00e9server la localit\u00e9 m\u00e9moire et d'\u00e9viter le swap. Dans les sc\u00e9narios tr\u00e8s fortement parall\u00e9lis\u00e9s, je v\u00e9rifie si les threads exploitent les c\u0153urs de mani\u00e8re optimale ou s'ils se bloquent mutuellement. En r\u00e9duisant le parall\u00e9lisme inutile, la surcharge diminue et la machine gagne sensiblement en performances. <strong>plus liquide<\/strong>.<\/p>\n\n<p>Pour les interfaces Web, je pr\u00e9vois un nombre de threads l\u00e9g\u00e8rement sup\u00e9rieur au nombre de c\u0153urs, car de nombreuses requ\u00eates sont en attente d'E\/S. Les bases de donn\u00e9es tirent profit d\u2019un parall\u00e9lisme judicieux et d\u2019une affinit\u00e9 bien g\u00e9r\u00e9e. Je regroupe les t\u00e2ches par lots dans des cr\u00e9neaux horaires o\u00f9 le trafic utilisateur est faible. Je place les op\u00e9rations de compression ou de transcodage gourmandes en ressources CPU dans des groupes distincts afin de ne pas nuire \u00e0 l\u2019interactivit\u00e9. Ces mod\u00e8les limitent les impr\u00e9vus et me permettent <strong>Contr\u00f4le<\/strong> sur les cons\u00e9quences de chaque modification.<\/p>\n\n<h2>Comprendre les priorit\u00e9s, les \u00ab nice \u00bb et les pond\u00e9rations<\/h2>\n\n<p>J'utilise les valeurs \u00ab nice \u00bb pour <strong>pond\u00e9ration<\/strong> d'un processus et, par l\u00e0 m\u00eame, sa part de temps CPU. Des valeurs \u00ab nice \u00bb faibles indiquent une importance plus \u00e9lev\u00e9e, tandis que des valeurs \u00ab nice \u00bb \u00e9lev\u00e9es limitent les t\u00e2ches en arri\u00e8re-plan. Je m'assure ainsi que les services essentiels r\u00e9agissent de mani\u00e8re fiable, tandis que les t\u00e2ches de maintenance sont mises en attente. De plus, je surveille le nombre de t\u00e2ches actives simultan\u00e9ment par groupe, car cela influence \u00e9galement la r\u00e9partition. Voici un aper\u00e7u de la classification des <a href=\"https:\/\/webhosting.de\/fr\/serveur-cpu-scheduler-planification-des-classes\/\">Classes de planification<\/a> Je m'en sers pour distinguer clairement le CFS des classes en temps r\u00e9el.<\/p>\n\n<p>La coh\u00e9rence reste essentielle : je documente les param\u00e8tres et je les maintiens identiques d\u2019un d\u00e9ploiement \u00e0 l\u2019autre. Sinon, des pond\u00e9rations diff\u00e9rentes selon les \u00e9tapes peuvent entra\u00eener des effets difficiles \u00e0 expliquer. En veillant \u00e0 la coh\u00e9rence, je rep\u00e8re plus rapidement les causes des valeurs aberrantes. Des \u00e9tapes petites et compr\u00e9hensibles facilitent les retours en arri\u00e8re si n\u00e9cessaire. Ainsi, l\u2019impact de <strong>Priorit\u00e9s<\/strong> transparent.<\/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\/08\/fair_scheduling_server_2390.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Virtualisation et conteneurs : deux niveaux de r\u00e9partition \u00e9quitable<\/h2>\n\n<p>Sur les hyperviseurs, les machines virtuelles se disputent les c\u0153urs du processeur h\u00f4te, tandis que le CFS orchestre les processus au sein de l'instance invit\u00e9e. Je d\u00e9finis les vCPU de mani\u00e8re r\u00e9aliste, plut\u00f4t que de faire des promesses en l'air qui, en cas de charge intense, <strong>voler<\/strong>. Dans les conteneurs, j\u2019utilise les parts de CPU et les quotas afin que les pics de charge de certains services n\u2019affectent pas l\u2019ensemble du n\u0153ud. La combinaison de l\u2019allocation h\u00f4te et de l\u2019\u00e9quit\u00e9 invit\u00e9 permet de maintenir des latences pr\u00e9visibles. Seuls des budgets clairement d\u00e9finis garantissent une exp\u00e9rience utilisateur agr\u00e9able et <strong>fiable<\/strong>.<\/p>\n\n<p>Sur les syst\u00e8mes NUMA, je tiens \u00e9galement compte de la localit\u00e9 m\u00e9moire. Lorsque les conteneurs se d\u00e9placent de mani\u00e8re al\u00e9atoire d'un socket \u00e0 l'autre, les latences m\u00e9moire augmentent et le d\u00e9bit diminue. Je lie donc les services sensibles \u00e0 des n\u0153uds sp\u00e9cifiques et je veille \u00e0 une liaison m\u00e9moire appropri\u00e9e. Cette approche r\u00e9duit les effets secondaires et favorise des temps de r\u00e9ponse homog\u00e8nes. Le CFS reste ici l'\u00e9l\u00e9ment central <strong>Instance<\/strong> par file d'attente d'ex\u00e9cution du processeur.<\/p>\n\n<h2>Suivi et r\u00e9glage progressif dans la pratique<\/h2>\n\n<p>Je commence par la configuration par d\u00e9faut, puis je mesure et j'ajuste ensuite. Des indicateurs tels que la longueur de la file d'attente d'ex\u00e9cution, le taux de changement de contexte, la saturation du processeur et les pourcentages par Cgroup permettent d'identifier les goulots d'\u00e9tranglement. Un nombre \u00e9lev\u00e9 de changements de contexte associ\u00e9 \u00e0 une charge CPU mod\u00e9r\u00e9e indique une granularit\u00e9 trop fine. Des files d\u2019attente d\u2019ex\u00e9cution longues accompagn\u00e9es de latences \u00e9lev\u00e9es sugg\u00e8rent un nombre trop important de threads actifs. Au final, ce qui compte, c\u2019est de savoir si les actions des utilisateurs produisent un effet plus rapide et si les graphiques refl\u00e8tent les r\u00e9sultats attendus. <strong>Tendance<\/strong> montrer.<\/p>\n\n<p>Je note chaque modification en pr\u00e9cisant la date, l'ampleur et l'objectif. Des tests de charge avant et apr\u00e8s la modification permettent de valider l'id\u00e9e. Si une approche \u00e9choue, j'annule la modification et j'essaie une autre combinaison. Je privil\u00e9gie les environnements de test s\u00e9par\u00e9s avant d\u2019intervenir sur les syst\u00e8mes de production. Cette discipline ne co\u00fbte pas grand-chose et permet de r\u00e9aliser d\u2019importantes \u00e9conomies par la suite. <strong>Temps<\/strong>.<\/p>\n\n<h2>Profils de performances pour l'h\u00e9bergement : sc\u00e9narios concrets<\/h2>\n\n<p>Pour une pile WordPress classique, j\u2019attribue des parts bien d\u00e9finies \u00e0 Nginx\/Apache, PHP-FPM et Redis, et je maintiens le nombre de workers PHP l\u00e9g\u00e8rement sup\u00e9rieur au nombre de c\u0153urs. La base de donn\u00e9es est prioritaire par rapport aux exportations par lots, afin que le processus de paiement et la recherche restent fluides. Je d\u00e9place le transcodage des m\u00e9dias vers des plages horaires \u201e calmes \u201c ou j\u2019applique des quotas plus stricts. Sur les n\u0153uds API, je limite davantage les t\u00e2ches en arri\u00e8re-plan afin de ma\u00eetriser les latences de queue. Dans tous les cas, je v\u00e9rifie si la <strong>Temps de r\u00e9ponse<\/strong> plus stable et que le d\u00e9bit reste constant.<\/p>\n\n<p>Dans les environnements partag\u00e9s, je pr\u00e9sente aux clients des budgets en euros par mois et je les traduis en quotas de CPU clairs. La transparence \u00e9vite les d\u00e9ceptions et facilite la vente incitative lorsque les pics de charge augmentent. Ce sont les donn\u00e9es mesur\u00e9es qui \u00e9tayent ces discussions, et non l'intuition. Je sais reconna\u00eetre quand un client devrait augmenter ses vCPU ou ses limites. Ainsi, les h\u00f4tes restent utilis\u00e9s de mani\u00e8re \u00e9quilibr\u00e9e et les performances globales s\u2019en trouvent am\u00e9lior\u00e9es. <strong>constant<\/strong>.<\/p>\n\n<h2>D\u00e9cision d'achat et choix d'un h\u00e9bergeur<\/h2>\n\n<p>Lorsque j'\u00e9value des offres, je v\u00e9rifie si le temps CPU est r\u00e9parti de mani\u00e8re \u00e9quitable en p\u00e9riode de forte charge et si l'isolation fonctionne de mani\u00e8re coh\u00e9rente. Quiconque compare des offres d'h\u00e9bergement, de serveurs ou de packs WordPress veille \u00e0 ce que les quotas soient clairs, les Cgroups bien d\u00e9finis et les donn\u00e9es de surveillance fiables. Les t\u00e9moignages et les benchmarks montrent comment les plateformes r\u00e9agissent aux heures de pointe. Dans les comparatifs, webhoster.de se classe souvent en t\u00eate lorsque l'\u00e9quit\u00e9 CPU et l'isolation convainquent clairement. J'\u00e9value cela de mani\u00e8re objective et je veille \u00e0 ce que le prix et <strong>Performance<\/strong> qui correspondent au profil de ses propres charges de travail.<\/p>\n\n<h2>Cgroup v2 en pratique : bien utiliser les param\u00e8tres `cpu.max` et `cpu.weight`<\/h2>\n\n<p>Sur les distributions modernes, je privil\u00e9gie Cgroup v2. Je r\u00e8gle les budgets CPU avec <strong>cpu.max<\/strong> et <strong>cpu.weight<\/strong>. Avec cpu.max, je d\u00e9finis un budget-temps fixe par p\u00e9riode (par exemple \u201e 50 ms 100 ms \u201c pour un CPU 50%). Si le deuxi\u00e8me chiffre n'est pas renseign\u00e9, la valeur par d\u00e9faut du syst\u00e8me s'applique. La <strong>pond\u00e9ration<\/strong> Je g\u00e8re cela avec `cpu.weight (1\u201310000) ; cela me permet de r\u00e9partir \u00e9quitablement la capacit\u00e9 restante lorsque plusieurs groupes sont actifs. Pour chaque service, je pr\u00e9cise s\u2019il n\u00e9cessite des limites strictes (par exemple, des t\u00e2ches par lots gourmandes en ressources) ou s\u2019il doit plut\u00f4t faire l\u2019objet d\u2019une pond\u00e9ration relative (API, bases de donn\u00e9es). Gr\u00e2ce \u00e0 des pond\u00e9rations coh\u00e9rentes par r\u00f4le, les h\u00f4tes restent planifiables et <strong>\u00e9quitable<\/strong>.<\/p>\n\n<p>L'\u00e9quilibre entre la pond\u00e9ration et le quota est essentiel : un quota serr\u00e9 prot\u00e8ge les voisins, mais peut entra\u00eener une limitation pr\u00e9coce en cas de pics de trafic de courte dur\u00e9e. Si la pond\u00e9ration suffit \u00e0 elle seule, je d\u00e9finis un quota g\u00e9n\u00e9reux, voire je m'en passe compl\u00e8tement. En p\u00e9riode de forte charge, une pond\u00e9ration l\u00e9g\u00e8rement plus \u00e9lev\u00e9e favorise l\u2019interactivit\u00e9, tandis que l\u2019archivage et les rapports se contentent d\u2019une pond\u00e9ration mod\u00e9r\u00e9e.<\/p>\n\n<h2>Le contr\u00f4le de la bande passante CFS en d\u00e9tail : p\u00e9riode, quota et limitation de d\u00e9bit<\/h2>\n\n<p>Le contr\u00f4le de bande passante CFS limite le temps CPU par Cgroup dans une plage d\u00e9finie <strong>P\u00e9riode<\/strong>. En g\u00e9n\u00e9ral, je d\u00e9finis \u00ab period \u00bb et \u00ab quota \u00bb (v1) ou \u00ab cpu.max \u00bb (v2). Si le budget est \u00e9puis\u00e9, <strong>r\u00e9duit<\/strong> CFS jusqu'\u00e0 la p\u00e9riode suivante. C'est pr\u00e9cis\u00e9ment l\u00e0 que des irr\u00e9gularit\u00e9s apparaissent facilement sur la courbe de latence. J'\u00e9vite les pics en ajustant la p\u00e9riode et la <strong>Taille de la tranche<\/strong> (kernel.sched_cfs_bandwidth_slice_us) en fonction de la charge de travail : des tranches plus petites permettent une r\u00e9partition plus fine de l'ex\u00e9cution, mais augmentent la surcharge. Pour les services pr\u00e9sentant des pics de trafic tr\u00e8s importants, je choisis une p\u00e9riode mod\u00e9r\u00e9e (par exemple 50 \u00e0 100 ms) et un budget suffisant pour que les pics de requ\u00eates typiques puissent passer sans \u00eatre limit\u00e9s.<\/p>\n\n<p>Si je constate des ralentissements fr\u00e9quents malgr\u00e9 une faible charge globale du processeur, cela signifie que le quota est trop serr\u00e9. J'augmente alors le budget en fonction de la charge de travail ou j'opte pour une pond\u00e9ration plut\u00f4t que pour des limites strictes. Si les goulots d'\u00e9tranglement ne sont que de courte dur\u00e9e, je r\u00e9partis les pics de charge sur plusieurs <strong>Travailleur<\/strong> avec un l\u00e9ger d\u00e9calage entre les activit\u00e9s, afin que les p\u00e9riodes ne soient pas vides en m\u00eame temps.<\/p>\n\n<h2>Utiliser \u00e0 bon escient le SMT, l'affinit\u00e9 IRQ et l'isolation des noyaux<\/h2>\n\n<p>Sur les syst\u00e8mes \u00e9quip\u00e9s de <strong>SMT\/Hyper-Threading<\/strong> Je tiens compte du fait que deux threads se partagent les unit\u00e9s d'ex\u00e9cution d'un c\u0153ur. Pour les front-ends o\u00f9 la latence est critique, je regroupe de pr\u00e9f\u00e9rence les threads actifs sur des c\u0153urs physiques d\u00e9di\u00e9s, tandis que les t\u00e2ches en arri\u00e8re-plan occupent les slots SMT associ\u00e9s. De plus, je configure <strong>Affinit\u00e9 IRQ<\/strong> pour les cartes r\u00e9seau et les files d'attente NVMe, en fonction des jeux de processeurs adapt\u00e9s. Ainsi, les Softirqs se retrouvent \u00e0 proximit\u00e9 des consommateurs <strong>Threads de travail<\/strong>, le nombre de coups de cache augmente et la gigue diminue.<\/p>\n\n<p>Si j\u2019ai besoin d\u2019une isolation stricte, je r\u00e9serve quelques c\u0153urs via les param\u00e8tres du noyau (par exemple, des c\u0153urs isol\u00e9s \u201e sans t\u00e2ches de maintenance \u201c). Je n\u2019y d\u00e9place que les services d\u00e9di\u00e9s ainsi que leurs interruptions, et j\u2019en tiens les threads syst\u00e8me \u00e0 l\u2019\u00e9cart. Ce faisant, je proc\u00e8de \u00e0 des tests minutieux pour m\u2019assurer que les services du noyau ne soient pas priv\u00e9s de ressources. Souvent, une affinit\u00e9 clairement d\u00e9finie, sans isolation totale, suffit pour obtenir des temps de r\u00e9ponse stables.<\/p>\n\n<h2>Mise \u00e0 l'\u00e9chelle de la fr\u00e9quence : r\u00e9gulateur et mode Turbo pour une latence constante<\/h2>\n\n<p>Le <strong>Fr\u00e9quence du processeur<\/strong> Cela influe sensiblement sur les latences de queue. Avec le r\u00e9gulateur \u201e schedutil \u201c, la fr\u00e9quence d\u2019horloge suit de pr\u00e8s la vision du planificateur en mati\u00e8re de charge. Pour les API sensibles \u00e0 la latence, j\u2019opte toutefois souvent pour le r\u00e9gulateur \u201e performance \u201c ou j\u2019augmente la fr\u00e9quence minimale afin que les c\u0153urs ne tombent pas dans des \u00e9tats P profonds. J\u2019utilise le Turbo Boost de mani\u00e8re cibl\u00e9e : il acc\u00e9l\u00e8re les courtes rafales, mais peut d\u00e9clencher le contr\u00f4le de la temp\u00e9rature et r\u00e9duire les fr\u00e9quences par la suite. Je mesure les temps de r\u00e9ponse avec et sans Turbo et je prends une d\u00e9cision pour chaque n\u0153ud. L'objectif est <strong>Constance<\/strong>, et non des valeurs maximales mesur\u00e9es en laboratoire.<\/p>\n\n<p>Sur des n\u0153uds mixtes, je combine : quelques c\u0153urs r\u00e9gl\u00e9s \u00e0 un niveau \u00e9lev\u00e9 pour l'interactivit\u00e9, le reste de mani\u00e8re dynamique pour le traitement par lots. Il est important de maintenir une politique \u00e9nerg\u00e9tique coh\u00e9rente sur l'h\u00f4te afin que les tests soient reproductibles et que l'effet du r\u00e9glage du CFS ne soit pas masqu\u00e9 par la logique d'\u00e9conomie d'\u00e9nergie.<\/p>\n\n<h2>Approfondir le diagnostic : tracepoints, perf et statistiques de planification<\/h2>\n\n<p>Lorsque les effets ne sont pas clairs, j'approfondis mon analyse. \u00c0 l'aide de \u00ab perf \u00bb et de \u00ab tracepoints \u00bb, j'examine <strong>R\u00e9veils<\/strong>, les changements de contexte et les temps d'attente dans la file d'attente d'ex\u00e9cution. Des constatations telles que \u201e de nombreuses pr\u00e9emptions peu apr\u00e8s le r\u00e9veil \u201c indiquent une valeur trop faible de `wakeup_granularity` ou un parall\u00e9lisme excessif. \/proc\/schedstat et \/proc\/sched_debug indiquent les dur\u00e9es d\u2019ex\u00e9cution, les taux de migration et la r\u00e9partition par CPU. Je mets ces valeurs en corr\u00e9lation avec les parts des Cgroups et les m\u00e9triques des applications jusqu\u2019\u00e0 ce que la <strong>Cause<\/strong> d'une onde de latence est perceptible.<\/p>\n\n<p>La valeur ajout\u00e9e r\u00e9sulte de la comparaison : m\u00eames tests avant et apr\u00e8s une modification, mod\u00e8les de charge identiques, plages horaires fixes. Ce n\u2019est qu\u2019alors que je proc\u00e8de \u00e0 une r\u00e9\u00e9valuation. Si les courbes de mesure pr\u00e9sentent du bruit, je r\u00e9duis le nombre de variables (par exemple, fr\u00e9quence fixe, nombre constant de threads) avant de modifier d\u2019autres param\u00e8tres.<\/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\/08\/kernel_scheduler_cfs_8945.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Aper\u00e7u des E\/S et du r\u00e9seau : Softirqs, RPS\/RFS et Block-Scheduler<\/h2>\n\n<p>La r\u00e9partition \u00e9quitable de la charge CPU ne fonctionne que si le chemin de donn\u00e9es suit le rythme. Je classe <strong>Softirqs<\/strong> (ksoftirqd) aux processeurs de l'application, afin que les paquets et leur traitement co\u00efncident g\u00e9ographiquement. Gr\u00e2ce \u00e0 des files d'attente NIC distribu\u00e9es et \u00e0 une affinit\u00e9 adapt\u00e9e, je d\u00e9sengorge les points de congestion. Lorsque le d\u00e9bit r\u00e9seau est \u00e9lev\u00e9, les param\u00e8tres RPS\/RFS et XPS permettent de r\u00e9partir la charge de mani\u00e8re plus \u00e9quilibr\u00e9e. C\u00f4t\u00e9 stockage, je veille \u00e0 choisir un planificateur d\u2019E\/S par blocs adapt\u00e9 et \u00e0 mettre en place un contr\u00f4le des E\/S par cgroups, afin que les applications gourmandes en E\/S ne r\u00e9duisent pas indirectement le temps CPU des autres. J\u2019\u00e9vite ainsi que l\u2019\u00e9quit\u00e9 au niveau du CPU ne soit compromise par <strong>Recul<\/strong> est contrecarr\u00e9 dans le chemin d'E\/S.<\/p>\n\n<p>Pour les charges de travail utilisant io_uring ou impliquant des E\/S asynchrones intensives, je pr\u00e9vois des ensembles ou des groupes de processeurs d\u00e9di\u00e9s aux threads d'assistance aux E\/S, afin qu'ils ne soient pas en concurrence avec les threads de travail du front-end pour le m\u00eame budget.<\/p>\n\n<h2>Anti-mod\u00e8les et guides pratiques \u00e9prouv\u00e9s<\/h2>\n\n<p>Dans la pratique, je constate r\u00e9guli\u00e8rement des sch\u00e9mas r\u00e9currents qui nuisent aux temps de r\u00e9ponse. Je les \u00e9vite syst\u00e9matiquement :<\/p>\n<ul>\n  <li>Trop de <strong>Fils de discussion<\/strong> Pour les services d\u00e9pendants du processeur : je m'approche du nombre de c\u0153urs et je fais de l'\u00e9volutivit\u00e9 horizontale, plut\u00f4t que de lancer des centaines de workers.<\/li>\n  <li>Trop \u00e9troite <strong>Cotes<\/strong> avec une p\u00e9riode courte : cela entra\u00eene des ondes de \u00ab throttle \u00bb. Mieux vaut : augmenter l\u00e9g\u00e8rement le budget ou la pond\u00e9ration.<\/li>\n  <li>Impr\u00e9cis <strong>affinit\u00e9<\/strong>: Les threads migrants qui sacrifient la localit\u00e9 du cache. Je fixe de mani\u00e8re coh\u00e9rente les chemins chauds et leurs interruptions.<\/li>\n  <li>Mixte <strong>\u00c9tapes<\/strong> avec des valeurs \u00ab nice \u00bb et \u00ab weight \u00bb diff\u00e9rentes : cela cr\u00e9e des surprises. J'harmonise les valeurs par d\u00e9faut.<\/li>\n  <li>Autogroup activ\u00e9 de mani\u00e8re globale : je teste son efficacit\u00e9 de mani\u00e8re cibl\u00e9e sur les serveurs ; les optimisations interactives du bureau ne sont pas toujours utiles dans le centre de donn\u00e9es.<\/li>\n<\/ul>\n\n<p>Mes playbooks sont pragmatiques : commencer par assurer la visibilit\u00e9 (m\u00e9triques, traces), puis intervenir au niveau des leviers g\u00e9n\u00e9raux (threads, cgroups), et enfin proc\u00e9der \u00e0 des r\u00e9glages fins (latence, granularit\u00e9). Chaque modification reste r\u00e9versible et document\u00e9e. Ainsi, l'environnement reste ma\u00eetrisable et <strong>pr\u00e9visible<\/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\/2026\/08\/hosting-serverraum-7482.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>En bref<\/h2>\n\n<p>Le <strong>CFS<\/strong> Le planificateur r\u00e9partit \u00e9quitablement le temps CPU, maintient un haut niveau d\u2019interactivit\u00e9 et reste la meilleure base de d\u00e9part pour les charges de travail d\u2019h\u00e9bergement mixtes. Il est essentiel de d\u00e9finir des limites adapt\u00e9es avec les Cgroups, d\u2019assurer un parall\u00e9lisme r\u00e9aliste et d\u2019\u00e9tablir des priorit\u00e9s claires. Je n'ajuste les valeurs de latence et de granularit\u00e9 que lorsque les mesures r\u00e9v\u00e8lent un goulot d'\u00e9tranglement. Je v\u00e9rifie ensuite l'effet obtenu et je reviens en arri\u00e8re si le r\u00e9sultat n'est pas convaincant. Gr\u00e2ce \u00e0 cette approche pragmatique, je garantis une <strong>Temps de r\u00e9ponse<\/strong> et des capacit\u00e9s pr\u00e9visibles \u2013 sans surcharger la machine.<\/p>","protected":false},"excerpt":{"rendered":"<p>Le planificateur CFS expliqu\u00e9 : planification \u00e9quitable dans le noyau Linux pour les serveurs d'h\u00e9bergement, les performances et une r\u00e9partition optimale de la charge CPU.<\/p>","protected":false},"author":1,"featured_media":20571,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20578","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":"98","_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":"CFS Scheduler","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":"20571","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20578","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=20578"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20578\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/20571"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=20578"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=20578"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=20578"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}