{"id":18689,"date":"2026-04-03T18:19:44","date_gmt":"2026-04-03T16:19:44","guid":{"rendered":"https:\/\/webhosting.de\/server-cpu-affinity-hosting-optimierung-kernelaffinity\/"},"modified":"2026-04-03T18:19:44","modified_gmt":"2026-04-03T16:19:44","slug":"serveur-cpu-affinity-hebergement-optimisation-kernelaffinity","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/server-cpu-affinity-hosting-optimierung-kernelaffinity\/","title":{"rendered":"Server CPU Affinity : Optimisation en mode d'h\u00e9bergement"},"content":{"rendered":"<p><strong>Serveur CPU Affinity<\/strong> affecte de mani\u00e8re cibl\u00e9e des processus \u00e0 des noyaux de CPU fixes, r\u00e9duisant ainsi les migrations, les changements de contexte et les caches froids dans les piles d'h\u00e9bergement. Je montre comment cet \u00e9pinglage cr\u00e9e des latences planifiables, des taux de r\u00e9ussite de cache plus \u00e9lev\u00e9s et un d\u00e9bit r\u00e9gulier dans les serveurs web, PHP-FPM, les bases de donn\u00e9es, les VM et les conteneurs.<\/p>\n\n<h2>Points centraux<\/h2>\n<p>Les aspects cl\u00e9s suivants constituent les garde-fous pour une mise en \u0153uvre efficace d'Affinity dans l'h\u00e9bergement.<\/p>\n<ul>\n  <li><strong>Proximit\u00e9 de la cache<\/strong> minimise la latence et augmente l'efficacit\u00e9 des charges de travail multithread\u00e9es.<\/li>\n  <li><strong>Planification<\/strong> gr\u00e2ce \u00e0 l'\u00e9pinglage : moins de valeurs aberrantes \u00e0 p99 et temps de r\u00e9ponse constant.<\/li>\n  <li><strong>Conscience de la NUMA<\/strong> couple m\u00e9moire et CPU, r\u00e9duit les acc\u00e8s \u00e0 distance co\u00fbteux.<\/li>\n  <li><strong>Cgroups<\/strong> compl\u00e8tent Affinity avec des quotas, des priorit\u00e9s et une r\u00e9partition \u00e9quitable.<\/li>\n  <li><strong>Suivi<\/strong> avec perf\/Prometheus r\u00e9v\u00e8le les migrations et les miss.<\/li>\n<\/ul>\n\n<h2>Que signifie CPU Affinity dans l'h\u00e9bergement ?<\/h2>\n\n<p>L'affinit\u00e9 lie <strong>Fils de discussion<\/strong> \u00e0 des noyaux fixes afin que l'ordonnanceur ne les disperse pas sur l'ensemble du socket. Ainsi, les caches L1\/L2\/L3 restent chauds, ce qui est particuli\u00e8rement important pour les applications sensibles \u00e0 la latence. <strong>Demandes sur le web<\/strong> compte. Par d\u00e9faut, le CFS de Linux s'\u00e9quilibre de mani\u00e8re dynamique, mais g\u00e9n\u00e8re des migrations superflues dans les phases chaudes. Je limite ces migrations de mani\u00e8re cibl\u00e9e au lieu de freiner compl\u00e8tement le planificateur. Je vous propose ici une introduction plus approfondie aux alternatives CFS : <a href=\"https:\/\/webhosting.de\/fr\/linux-scheduler-cfs-alternatives-hebergement-kernelperf-boost\/\">Options de l'ordonnanceur Linux<\/a>.<\/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\/2026\/04\/cpu-affinity-serverraum-1842.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Analyse de la charge de travail et profilage<\/h2>\n\n<p>Avant d'\u00e9pingler, j'examine <strong>Caract\u00e9ristiques<\/strong> des services. Les serveurs web \u00e9v\u00e9nementiels g\u00e9n\u00e8rent peu de changements de contexte, mais b\u00e9n\u00e9ficient fortement de la coh\u00e9rence du cache. Les bases de donn\u00e9es sont sensibles aux migrations du noyau pendant les jointures ou les points de contr\u00f4le intensifs. Je mesure la latence p95\/p99, je suis les migrations du CPU avec <strong>parfait<\/strong> et je regarde les LLC-misses. Ce n'est qu'ensuite que j'\u00e9cris des r\u00e8gles fixes et que je les teste sous charge de pointe.<\/p>\n\n<h2>Topologie du CPU, SMT et paires de c\u0153urs<\/h2>\n<p>Je tiens compte de la topologie physique : complexes de base, tranches L3 et <strong>SMT<\/strong>-des fr\u00e8res et s\u0153urs. Pour les services critiques en termes de latence de queue, je n'occupe qu'un seul thread SMT par c\u0153ur afin que les threads chauds ne se partagent pas les unit\u00e9s d'ex\u00e9cution. SMT reste actif pour les t\u00e2ches par lots qui profitent du d\u00e9bit suppl\u00e9mentaire. Sur AMD-EPYC, je fais attention aux limites CCD\/CCX : Les travailleurs restent \u00e0 l'int\u00e9rieur d'un segment L3 afin que les hits LLC restent \u00e9lev\u00e9s et stables. Sur les piles \u00e0 forte charge NIC, j'apparie les queues RX\/TX avec les <strong>Noyaux<\/strong>, sur lesquels fonctionnent les workers de l'espace utilisateur. Cet appariement permet d'\u00e9viter les snoops cross-core et de maintenir les chemins entre IRQ, SoftIRQ et App courts.<\/p>\n\n<h2>Strat\u00e9gies d'\u00e9pinglage pour les serveurs web et PHP-FPM<\/h2>\n\n<p>Pour les frontaux web, j'utilise <strong>NGINX<\/strong> souvent sur un ensemble de noyaux \u00e9troits, par exemple 0-3, afin de garantir des temps de r\u00e9ponse r\u00e9guliers. Je divise PHP-FPM : hot-worker sur 4-7, jobs d'arri\u00e8re-plan sur 8-11. J'all\u00e8ge Node.js avec des worker-threads et je lie les t\u00e2ches n\u00e9cessitant beaucoup de CPU \u00e0 des t\u00e2ches propres. <strong>noyaux<\/strong>. Je maintiens Apache dans le MPM \u00e9v\u00e9nementiel avec des limites strictes dans des files d'attente d'ex\u00e9cution courtes. De telles dispositions permettent de maintenir les pipelines propres et de r\u00e9duire sensiblement la gigue.<\/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\/04\/server_cpu_affinity_3621.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Param\u00e8tres du noyau et de l'ordonnanceur dans le contexte d'Affinity<\/h2>\n<p>L'affinit\u00e9 a plus d'effet si le noyau ne contrecarre pas en permanence. Pour les services fortement sensibles au cache, j'augmente la <strong>sched_migration_cost_ns<\/strong>, Le CFS doit donc moins souvent consid\u00e9rer les migrations comme \u201ebon march\u00e9\u201c. <strong>sched_min_granularity_ns<\/strong> et <strong>sched_wakeup_granularity_ns<\/strong> influencent les tranches de temps et le comportement de pr\u00e9emption ; j'avance ici \u00e0 t\u00e2tons dans des tests A\/B. Pour les noyaux de latence isol\u00e9s, j'utilise de mani\u00e8re cibl\u00e9e des <em>housekeeping<\/em>-CPUs et placer des threads RCU\/noyau \u00e0 l'\u00e9cart des c\u0153urs chauds (nohz_full\/rcu_nocbs sur des h\u00f4tes s\u00e9lectionn\u00e9s). Ces interventions sont <strong>en fonction du contexte<\/strong>Je ne les modifie que par classe de charge de travail et je les remets en place en les surveillant de pr\u00e8s si la variance ou le d\u00e9bit en p\u00e2tissent.<\/p>\n\n<h2>Bases de donn\u00e9es et masques Affinity<\/h2>\n\n<p>Dans les bases de donn\u00e9es, une bonne <strong>Affectation<\/strong> Transactions en ligne, t\u00e2ches de maintenance et gestion des E\/S. SQL Server prend en charge les masques d'affinit\u00e9, qui me permettent de d\u00e9finir des ensembles d'unit\u00e9s centrales pour les threads du moteur et s\u00e9par\u00e9ment pour les E\/S. J'\u00e9vite les chevauchements entre les masques d'affinit\u00e9 et les masques d'E\/S, sinon les threads \u00e0 chaud entrent en concurrence avec les E\/S en bloc. Pour les h\u00f4tes de plus de 32 c\u0153urs, j'utilise les masques 64 bits \u00e9tendus. Ainsi, les log-flushers, les checkpointers et les query-workers restent propres les uns par rapport aux autres. <strong>isol\u00e9<\/strong>.<\/p>\n\n<h2>Chemins de stockage et files d'attente NVMe<\/h2>\n<p>\u00c0 l'adresse suivante : <strong>blk-mq<\/strong> je mappe les files d'attente NVMe et de stockage sur les c\u0153urs du m\u00eame domaine NUMA que les DB-workers. Les threads de flux de logs et les IRQ des files NVMe correspondantes atterrissent sur des c\u0153urs voisins, afin que les confirmations d'\u00e9criture ne traversent pas la socket. Je veille \u00e0 ce que les app-threads et les IRQ de stockage fortement sollicit\u00e9es ne partagent pas le m\u00eame noyau, sinon des blocs de t\u00eate de ligne apparaissent. J'utilise les ordonnanceurs multi-files de mani\u00e8re \u00e0 ce que le nombre de files d'attente corresponde au nombre de c\u0153urs effectivement allou\u00e9s - trop de files d'attente ne font qu'augmenter les frais g\u00e9n\u00e9raux, trop peu de files d'attente g\u00e9n\u00e8rent une contention de verrouillage.<\/p>\n\n<h2>Virtualisation, vCPU pinning et NUMA<\/h2>\n\n<p>Dans KVM ou Hyper-V, je couple <strong>vCPU<\/strong> aux noyaux physiques pour \u00e9viter le steal time. Je s\u00e9pare les files d'attente vhost-net\/virtio des noyaux chauds des invit\u00e9s afin que IO ne ralentisse pas les threads des applications. NUMA exige en outre de garder un \u0153il sur la localisation de la m\u00e9moire, sinon les temps d'acc\u00e8s sont doubl\u00e9s. Pour plus d'informations sur les topologies et le r\u00e9glage, je vous renvoie \u00e0 cet article : <a href=\"https:\/\/webhosting.de\/fr\/blog-numa-architecture-serveur-performance-hebergement-materiel-optimisation-infrastructure\/\">Architecture NUMA dans l'h\u00e9bergement<\/a>. Dans les configurations denses, ce couplage apporte une plus grande r\u00e9gularit\u00e9. <strong>Latence<\/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\/04\/cpu-affinity-optimization-7253.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Orchestration de conteneurs : politiques de cpuset et QoS<\/h2>\n<p>Dans les conteneurs, je mets <strong>cpuset.cpus<\/strong> coh\u00e9rent avec les quotas CPU. Kubernetes fournit avec le gestionnaire de CPU (politique \u201estatic\u201c) des c\u0153urs exclusifs pour les pods dans la classe de QoS Guaranteed, lorsque Requests=Limits sont d\u00e9finis. Ainsi, les pods critiques atterrissent sur des c\u0153urs fixes, tandis que les charges de travail Best-Effort restent flexibles. Je planifie les pods en tenant compte de la topologie : je r\u00e9partis les chemins de latence (Ingress, App, Cache) par n\u0153ud NUMA afin que la m\u00e9moire et la charge IRQ restent locales. Ce qui est important, c'est la <strong>Planification<\/strong> \u00e9galement lors de rollouts : les r\u00e9pliques re\u00e7oivent des ensembles de noyaux identiques, sinon les valeurs de mesure d\u00e9rivent entre les instances.<\/p>\n\n<h2>Cgroupes, \u00e9quit\u00e9 et isolement<\/h2>\n\n<p>Affinity seul ne garantit pas <strong>\u00c9quit\u00e9<\/strong>, c'est pourquoi je les combine avec les cgroupes. cpu.shares donne une priorit\u00e9 relative aux groupes, cpu.max fixe des limites sup\u00e9rieures strictes par tranche de temps. Cela me permet de contenir les voisins bruyants, m\u00eame s'ils sont connect\u00e9s au CPU. Dans l'h\u00e9bergement multi-locataires, je s\u00e9curise les services critiques avec des shares plus \u00e9lev\u00e9s. Ensemble, ils forment un syst\u00e8me clair <strong>S\u00e9paration<\/strong> sans risque d'overcommit.<\/p>\n\n<h2>Gestion de l'\u00e9nergie et des fr\u00e9quences pour des latences pr\u00e9visibles<\/h2>\n<p>Les Power-States influencent sensiblement la gigue. Pour les objectifs stricts de p99, je maintiens des fr\u00e9quences de base \u00e9lev\u00e9es et stables sur les c\u0153urs chauds (performance du gouverneur, ou fr\u00e9quence de base \u00e9lev\u00e9e). <em>energy_performance_preference<\/em>) et je limite les C-States bas pour que les temps de r\u00e9veil ne soient pas dominants. J'utilise le turbo avec mod\u00e9ration : les threads individuels en profitent, mais les limites thermiques peuvent emp\u00eacher l'ex\u00e9cution en parall\u00e8le de certains processus. <strong>noyaux<\/strong> de la vitesse. Pour obtenir un d\u00e9bit r\u00e9gulier, je fixe des limites de fr\u00e9quence sup\u00e9rieures\/inf\u00e9rieures par socket et je place la logique d'\u00e9conomie d'\u00e9nergie sur les c\u0153urs froids. Cela permet de r\u00e9duire la variance sans limiter le d\u00e9bit global de mani\u00e8re excessive.<\/p>\n\n<h2>systemd, taskset et Windows : mise en \u0153uvre<\/h2>\n\n<p>Pour les services permanents, j'utilise <strong>systemd<\/strong> avec CPUAffinity=0-3 dans l'unit\u00e9, combin\u00e9 avec CPUSchedulingPolicy=fifo pour les charges de travail RT. Je d\u00e9marre les t\u00e2ches uniques avec taskset -c 4-7, afin que les sauvegardes ne soient pas envoy\u00e9es dans des caches \u00e0 chaud. J'encapsule les conteneurs via cpuset.cpus et cgroupv2 pour que les pods aient leurs noyaux fixes. Sous Windows, je r\u00e8gle le ProcessorAffinity sur un hex de masque de bits via PowerShell. Ces options me donnent des informations pr\u00e9cises <strong>Contr\u00f4le<\/strong> jusqu'\u00e0 la limite du noyau.<\/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\/04\/cpu_affinity_optimization_9876.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoring et tests : mesurer au lieu de deviner<\/h2>\n\n<p>Je v\u00e9rifie le succ\u00e8s avec <strong>parfait<\/strong> (context-switches, migrations, cache-misses) et suit p95\/p99 par timeseries. Les reproductions de charge de travail avec wrk, hey ou sysbench montrent si les valeurs aberrantes diminuent. En outre, j'observe le temps de vol dans les VM et la charge IRQ sur les noyaux h\u00f4tes. Une br\u00e8ve comparaison A\/B sous charge de pointe met en \u00e9vidence les hypoth\u00e8ses erron\u00e9es. Ce n'est qu'une fois que les chiffres correspondent que je fige les r\u00e8gles en tant que r\u00e8gles permanentes. <strong>Politiques<\/strong> un.<\/p>\n\n<h2>Risques, limites et anti-patterns<\/h2>\n\n<p>L'\u00e9pinglage rigide peut \u00eatre des noyaux <strong>tourner \u00e0 vide<\/strong> si le trafic varie. C'est pourquoi je ne fixe que les threads critiques et laisse les threads non critiques sur le programmateur. L'overcommit consomme \u00e9galement de l'utilit\u00e9 lorsque deux VM bruyantes veulent le m\u00eame noyau. Si l'on fixe trop, on se heurte plus tard \u00e0 des points chauds et \u00e0 une mauvaise utilisation. Une bonne v\u00e9rification de la r\u00e9alit\u00e9 : cet article sur le CPU pinning est <a href=\"https:\/\/webhosting.de\/fr\/cpu-pinning-hosting-rarement-utile-optimisation-reglage\/\">rarement utile<\/a> appelle \u00e0 une utilisation mesur\u00e9e, avec des objectifs clairs et des <strong>M\u00e9triques<\/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\/04\/server_cpu_affinity_1984.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Les cas sp\u00e9ciaux : Haute fr\u00e9quence et temps r\u00e9el<\/h2>\n\n<p>Pour les sub-millisecondes, je relie <strong>Affinity<\/strong> avec la politique RT, le r\u00e9glage des IRQ et la coh\u00e9rence NUMA. Je lie les IRQ r\u00e9seau \u00e0 leurs propres noyaux et je tiens les threads de l'espace utilisateur \u00e0 l'\u00e9cart. Sur les EPYC AMD avec topologie \u00e0 puce, je s\u00e9curise les chemins courts entre le c\u0153ur, le contr\u00f4leur de m\u00e9moire et la carte r\u00e9seau. Les grandes pages (HugeTLB) aident \u00e0 r\u00e9duire les taux d'\u00e9chec TLB. Ces \u00e9tapes r\u00e9duisent consid\u00e9rablement la variance et cr\u00e9ent <strong>Planification<\/strong> chez HF-Traffic.<\/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\/04\/serverraum-cpu-affinitat-8291.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ajustement fin pour les piles populaires<\/h2>\n\n<p>\u00c0 l'adresse suivante : <strong>PHP-FPM<\/strong> je place pm dynamic avec pm.max_children et process_idle_timeout correspondants, afin d'\u00e9liminer les worker inoccup\u00e9s. NGINX fonctionne avec worker_processes auto, mais je lie les travailleurs de mani\u00e8re cibl\u00e9e aux noyaux chauds. Je garde Apache dans event-MPM bri\u00e8vement connect\u00e9, afin que la file d'attente d'ex\u00e9cution n'augmente pas. Pour Node.js, j'encapsule la charge CPU dans des threads de travail avec leur propre affinit\u00e9. La boucle d'\u00e9v\u00e9nements reste ainsi libre et r\u00e9active. <strong>rapide<\/strong> sur les E\/S.<\/p>\n\n<h2>Contr\u00f4le IRQ et s\u00e9paration des E\/S<\/h2>\n\n<p>J'\u00e9pingle <strong>IRQ<\/strong>-sur des c\u0153urs d\u00e9di\u00e9s via smp_affinity, afin que les flux de paquets ne suppriment pas les threads d'applications. Je partage les cartes r\u00e9seau multi-utilisateurs sur plusieurs c\u0153urs, en fonction de la r\u00e9partition des flux RSS. Je s\u00e9pare les interruptions de stockage des IRQ r\u00e9seau afin d'\u00e9viter le head-of-line blocking. Les E\/S asynchrones et les threadpools dans NGINX emp\u00eachent les syscalls bloquants sur les c\u0153urs chauds. Cette s\u00e9paration permet de raccourcir les chemins et de prot\u00e9ger <strong>Charge de pointe<\/strong>.<\/p>\n\n<h2>Guide d'introduction progressive<\/h2>\n\n<p>Je commence avec <strong>Profilage<\/strong> sous Real-Traffic, puis je ne d\u00e9finis que les services critiques. Ensuite, je v\u00e9rifie p95\/p99 et les migrations avant de lier d'autres threads. Les cgroups me donnent des possibilit\u00e9s de correction sans red\u00e9marrage. Je documente les modifications par h\u00f4te et regroupe les r\u00e8gles dans des unit\u00e9s systemd. Ce n'est qu'apr\u00e8s avoir obtenu des valeurs de mesure stables que je d\u00e9roule les <strong>Configuration<\/strong> large.<\/p>\n\n<h2>Exploitation, gestion du changement et retour en arri\u00e8re<\/h2>\n<p>Je traite les r\u00e8gles d'affinit\u00e9 comme du code. Je versionne les unit\u00e9s systemd et les politiques de cgroup, je les d\u00e9roule <strong>staged<\/strong> (d'abord Canaries, puis plus large) et pr\u00e9pare un retour clair. Un retour rapide est obligatoire en cas de rupture des SLO p99 ou de baisse du d\u00e9bit. Je g\u00e8le les changements avant les p\u00e9riodes de pic et j'observe apr\u00e8s chaque \u00e9tape les taux de migration, les taux d'\u00e9chec LLC et l'utilisation par noyau. Cela permet de r\u00e9duire les risques op\u00e9rationnels et d'\u00e9viter que les \u201ebonnes\u201c optimisations individuelles ne produisent des effets secondaires ind\u00e9sirables lorsqu'elles sont combin\u00e9es.<\/p>\n\n<h2>Effets de s\u00e9curit\u00e9 et d'isolation<\/h2>\n<p>Affinity aide aussi \u00e0 <strong>Isolation<\/strong>Dans les environnements multi-locataires, je ne partage pas les fr\u00e8res et s\u0153urs SMT entre les clients afin de minimiser la diaphonie et les canaux lat\u00e9raux. Les services sensibles fonctionnent sur des c\u0153urs exclusifs, s\u00e9par\u00e9s des sources IRQ bruyantes. Les migrations du noyau contre les lacunes d'ex\u00e9cution sp\u00e9culative augmentent les co\u00fbts de changement de contexte - un \u00e9pinglage propre att\u00e9nue l'effet, car moins de threads se d\u00e9placent sur les limites des tuiles. Important : \u00e9quilibrer les objectifs de s\u00e9curit\u00e9 et les objectifs de performance ; parfois, \u201eSMT off\u201c est justifi\u00e9 pour quelques charges de travail particuli\u00e8rement sensibles \u00e0 la protection, tandis que le reste continue \u00e0 profiter du d\u00e9bit SMT.<\/p>\n\n<h2>KPIs, SLOs et rentabilit\u00e9<\/h2>\n<p>Je d\u00e9finis <strong>\u00e0 l'avance<\/strong> des KPI clairs : latence p95\/p99, d\u00e9bit, cs\/req (commutateurs contextuels par requ\u00eate), migrations par seconde et taux de d\u00e9faillance LLC. Des corridors cibles aident \u00e0 \u00e9valuer les trade-off, par exemple \u201ep99 -25% pour \u22645% de d\u00e9bit max en moins\u201c. Au niveau de l'h\u00f4te, j'observe l'\u00e9quilibre du c\u0153ur et le temps d'inactivit\u00e9 afin que l'\u00e9pinglage ne conduise pas \u00e0 une inoccupation co\u00fbteuse. L'affinit\u00e9 est \u00e9conomiquement judicieuse si la pr\u00e9visibilit\u00e9 obtenue r\u00e9duit les p\u00e9nalit\u00e9s SLO ou augmente la densit\u00e9 dans les clusters, car les tampons de r\u00e9serve peuvent \u00eatre plus petits. Sans ces chiffres, l'\u00e9pinglage reste une intuition - avec elle, il devient une solution solide. <strong>Optimisation<\/strong>.<\/p>\n\n<h2>R\u00e9trospective et mise en perspective<\/h2>\n\n<p>Affinity livre sur <strong>Serveurs<\/strong> avec un grand nombre de c\u0153urs offrent souvent une pr\u00e9visibilit\u00e9 \u00e9tonnante pour de faibles interventions. Dans les VM avec overcommit ou un trafic tr\u00e8s fluctuant, j'\u00e9trangle l'intervention. La conscience de la NUMA, le r\u00e9glage de l'IRQ et des quotas \u00e9quitables sont d\u00e9cisifs pour le succ\u00e8s. Sans monitoring, l'\u00e9pinglage devient vite un fardeau, avec des chiffres, il reste un outil. Celui qui proc\u00e8de de mani\u00e8re s\u00e9lective est gagnant <strong>Pr\u00e9visibilit\u00e9<\/strong> et utilise le mat\u00e9riel de mani\u00e8re efficace.<\/p>\n\n<h2>R\u00e9sum\u00e9<\/h2>\n\n<p>J'utilise <strong>Affinity CPU pour serveurs<\/strong>, J'utilise des outils d'affinage pour maintenir les fils d'attente \u00e0 chaud pr\u00e8s de leurs donn\u00e9es, r\u00e9duire les migrations et lisser les pics de latence. Dans les serveurs web, PHP-FPM, bases de donn\u00e9es et VMs, je combine Affinity avec Cgroups, IRQ-Tuning et NUMA-Discipline. Les options Systemd, taskset et Container-cpusets rendent la mise en \u0153uvre utilisable au quotidien. Je s\u00e9curise l'effet \u00e0 l'aide de mesures parf et de s\u00e9ries chronologiques et j'agis progressivement sur les r\u00e9gulateurs. En utilisant l'\u00e9pinglage de mani\u00e8re cibl\u00e9e, on obtient des temps de r\u00e9ponse constants, des caches propres et une augmentation mesurable de la performance. <strong>D\u00e9bit<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Server CPU Affinity optimise les performances d'h\u00e9bergement gr\u00e2ce au process pinning et au tuning. Moins de latence, plus de d\u00e9bit - des conseils pratiques.<\/p>","protected":false},"author":1,"featured_media":18682,"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-18689","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":"539","_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":"Server CPU Affinity","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":"18682","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/18689","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=18689"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/18689\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/18682"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=18689"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=18689"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=18689"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}