{"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":"servidor-cpu-affinity-hosting-otimizacao-kernelaffinity","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/server-cpu-affinity-hosting-optimierung-kernelaffinity\/","title":{"rendered":"Afinidade da CPU do servidor: otimiza\u00e7\u00e3o do funcionamento do alojamento"},"content":{"rendered":"<p><strong>Afinidade com a CPU do servidor<\/strong> atribui especificamente processos a n\u00facleos de CPU fixos e, assim, reduz migra\u00e7\u00f5es, trocas de contexto e caches frios em pilhas de hospedagem. Mostro como essa fixa\u00e7\u00e3o cria lat\u00eancias previs\u00edveis, taxas de acerto de cache mais altas e rendimento consistente em servidores Web, PHP-FPM, bancos de dados, VMs e cont\u00eaineres.<\/p>\n\n<h2>Pontos centrais<\/h2>\n<p>Os seguintes aspectos fundamentais constituem as diretrizes para a aplica\u00e7\u00e3o eficaz do Affinity no alojamento.<\/p>\n<ul>\n  <li><strong>Proximidade da cache<\/strong> minimiza a lat\u00eancia e aumenta a efici\u00eancia de cargas de trabalho multithread.<\/li>\n  <li><strong>Planeamento<\/strong> atrav\u00e9s da fixa\u00e7\u00e3o: menos anomalias no p99 e tempos de resposta constantes.<\/li>\n  <li><strong>Consci\u00eancia NUMA<\/strong> casais de mem\u00f3ria e CPU, reduz o acesso remoto dispendioso.<\/li>\n  <li><strong>Grupos C<\/strong> complementar a Afinidade com quotas, prioridades e distribui\u00e7\u00e3o equitativa.<\/li>\n  <li><strong>Monitoriza\u00e7\u00e3o<\/strong> com o perf\/Prometheus revela migra\u00e7\u00f5es e falhas.<\/li>\n<\/ul>\n\n<h2>O que significa CPU Affinity em hosting?<\/h2>\n\n<p>Liga\u00e7\u00f5es por afinidade <strong>T\u00f3picos<\/strong> em n\u00facleos fixos para que o agendador n\u00e3o os espalhe por todo o soquete. Isso mant\u00e9m os caches L1\/L2\/L3 aquecidos, o que \u00e9 particularmente importante para os sistemas cr\u00edticos de lat\u00eancia <strong>Consultas na Web<\/strong> conta. O CFS do Linux faz o balanceamento din\u00e2mico por padr\u00e3o, mas gera migra\u00e7\u00f5es sup\u00e9rfluas nas fases quentes. Eu especificamente limito essas migra\u00e7\u00f5es ao inv\u00e9s de diminuir a velocidade do agendador completamente. Eu forne\u00e7o uma introdu\u00e7\u00e3o mais aprofundada \u00e0s alternativas do CFS aqui: <a href=\"https:\/\/webhosting.de\/pt\/linux-scheduler-cfs-alternative-hosting-kernelperf-boost\/\">Op\u00e7\u00f5es do programador 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>An\u00e1lise e carateriza\u00e7\u00e3o da carga de trabalho<\/h2>\n\n<p>Antes de fazer o pin, examino o <strong>Carater\u00edstica<\/strong> dos servi\u00e7os. Os servidores Web orientados para eventos geram poucas altera\u00e7\u00f5es de contexto, mas beneficiam muito da coer\u00eancia da cache. As bases de dados s\u00e3o sens\u00edveis \u00e0s migra\u00e7\u00f5es do kernel durante jun\u00e7\u00f5es intensivas ou pontos de controlo. Me\u00e7o a lat\u00eancia p95\/p99, controlo as migra\u00e7\u00f5es da CPU com <strong>perfeito<\/strong> e procuro os erros da LLC. S\u00f3 depois \u00e9 que escrevo regras fixas e testo-as sob carga m\u00e1xima.<\/p>\n\n<h2>Topologia da CPU, SMT e pares de n\u00facleos<\/h2>\n<p>Tenho em conta a topologia f\u00edsica: complexos de n\u00facleos, cortes L3 e <strong>SMT<\/strong>-irm\u00e3os. Para servi\u00e7os cr\u00edticos de lat\u00eancia de cauda, eu aloco apenas uma thread SMT por n\u00facleo para que as threads quentes n\u00e3o compartilhem unidades de execu\u00e7\u00e3o. O SMT permanece ativo para trabalhos em lote que se beneficiam da taxa de transfer\u00eancia adicional. No AMD-EPYC, presto aten\u00e7\u00e3o aos limites de CCD\/CCX: Os trabalhadores ficam dentro de um segmento L3 para manter os acessos LLC est\u00e1veis e altos. Para pilhas com muitas placas de rede, eu emparelho as filas RX\/TX com o <strong>N\u00facleos<\/strong>, no qual os trabalhadores do espa\u00e7o do utilizador s\u00e3o executados. Este emparelhamento evita snoops entre n\u00facleos e mant\u00e9m os caminhos entre IRQ, SoftIRQ e app curtos.<\/p>\n\n<h2>Estrat\u00e9gias de fixa\u00e7\u00e3o para servidores Web e PHP-FPM<\/h2>\n\n<p>Para front-ends da Web, utilizo <strong>NGINX<\/strong> Costumo usar um conjunto de n\u00facleos estreito, por exemplo, 0-3, para garantir tempos de resposta consistentes. Eu divido o PHP-FPM: trabalhadores quentes em 4-7, trabalhos em segundo plano em 8-11. Eu alivio o Node.js com threads de trabalho e atribuo tarefas pesadas da CPU aos meus pr\u00f3prios threads de trabalho. <strong>n\u00facleos<\/strong>. Eu mantenho o Apache no evento MPM com limites apertados em filas de curta dura\u00e7\u00e3o. Esses layouts mant\u00eam os pipelines limpos e reduzem visivelmente o jitter.<\/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>Par\u00e2metros do kernel e do programador no contexto do Affinity<\/h2>\n<p>A afinidade tem um efeito mais forte se o kernel n\u00e3o a neutralizar permanentemente. Para servi\u00e7os altamente sens\u00edveis ao cache, eu aumento o <strong>sched_migration_cost_ns<\/strong>, para que o CFS considere as migra\u00e7\u00f5es \u201ebaratas\u201c com menos frequ\u00eancia. <strong>sched_min_granularity_ns<\/strong> e <strong>sched_wakeup_granularity_ns<\/strong> influenciam as frac\u00e7\u00f5es de tempo e o comportamento de preemp\u00e7\u00e3o; neste caso, utilizo testes A\/B. Para kernels de lat\u00eancia isolada, utilizo especificamente <em>servi\u00e7o de limpeza<\/em>-CPUs e colocar os threads RCU\/kernel longe dos n\u00facleos quentes (nohz_full\/rcu_nocbs em hosts selecionados). Estas interven\u00e7\u00f5es s\u00e3o <strong>dependente do contexto<\/strong>S\u00f3 os altero por classe de carga de trabalho e volto a alter\u00e1-los com um controlo rigoroso se a varia\u00e7\u00e3o ou o rendimento forem afectados.<\/p>\n\n<h2>Bases de dados e m\u00e1scaras de afinidade<\/h2>\n\n<p>Nas bases de dados, um bom <strong>Atribui\u00e7\u00e3o<\/strong> Transac\u00e7\u00f5es em linha, tarefas de manuten\u00e7\u00e3o e tratamento de E\/S. O SQL Server suporta m\u00e1scaras de afinidade, que utilizo para definir conjuntos de CPU para threads de motor e separadamente para E\/S. Evito sobreposi\u00e7\u00f5es entre a m\u00e1scara de afinidade e a m\u00e1scara de E\/S, caso contr\u00e1rio as threads quentes competem com a E\/S de bloco. Para hosts com mais de 32 n\u00facleos, uso as m\u00e1scaras estendidas de 64 bits. Isso mant\u00e9m os flushers de log, os check pointers e os query workers limpos uns dos outros <strong>isolado<\/strong>.<\/p>\n\n<h2>Caminhos de armazenamento e filas NVMe<\/h2>\n<p>Em <strong>blk-mq<\/strong> Eu mapeio as filas NVMe e de armazenamento para n\u00facleos no mesmo dom\u00ednio NUMA que os trabalhadores de banco de dados. As threads de descarga de log e os IRQs de fila NVMe associados aterram em n\u00facleos vizinhos para que as confirma\u00e7\u00f5es de grava\u00e7\u00e3o n\u00e3o sejam executadas atrav\u00e9s do soquete. Certifico-me de que as threads de aplicativos e os IRQs de armazenamento muito usados n\u00e3o compartilham o mesmo n\u00facleo, caso contr\u00e1rio, s\u00e3o criados blocos de cabe\u00e7a de linha. Utilizo agendadores de filas m\u00faltiplas de forma a que o n\u00famero de filas corresponda aos n\u00facleos efetivamente atribu\u00eddos - demasiadas filas apenas aumentam a sobrecarga, muito poucas criam reten\u00e7\u00e3o de bloqueios.<\/p>\n\n<h2>Virtualiza\u00e7\u00e3o, fixa\u00e7\u00e3o de vCPUs e NUMA<\/h2>\n\n<p>No KVM ou no Hyper-V, eu acoplo <strong>vCPUs<\/strong> para n\u00facleos f\u00edsicos para evitar roubo de tempo. Eu separo as filas do vhost-net\/virtio dos n\u00facleos quentes dos convidados para evitar que o IO acelere as threads do aplicativo. O NUMA tamb\u00e9m requer um olho na localidade da mem\u00f3ria, caso contr\u00e1rio os tempos de acesso duplicam. Para obter informa\u00e7\u00f5es mais detalhadas sobre topologias e ajustes, consulte este artigo: <a href=\"https:\/\/webhosting.de\/pt\/blog-numa-arquitetura-servidor-desempenho-alojamento-hardware-otimizacao-infraestrutura\/\">Arquitetura NUMA em alojamento<\/a>. Em configura\u00e7\u00f5es densas, este acoplamento produz um resultado visivelmente mais uniforme <strong>Lat\u00eancias<\/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>Orquestra\u00e7\u00e3o de contentores: pol\u00edticas de cpuset e QoS<\/h2>\n<p>Nos recipientes, coloco <strong>cpuset.cpus<\/strong> consistente com as cotas de CPU. O Kubernetes usa o gerenciador de CPU (pol\u00edtica \u201eest\u00e1tica\u201c) para fornecer n\u00facleos exclusivos para pods na classe QoS Garantida se Requests=Limits for definido. Isso significa que os pods cr\u00edticos aterrissam em n\u00facleos fixos, enquanto as cargas de trabalho de melhor esfor\u00e7o permanecem flex\u00edveis. Planeio os pods com consci\u00eancia topol\u00f3gica: divido os caminhos de lat\u00eancia (entrada, aplica\u00e7\u00e3o, cache) por n\u00f3 NUMA para que a mem\u00f3ria e a carga IRQ permane\u00e7am locais. Importante \u00e9 a <strong>Planeamento<\/strong> tamb\u00e9m para implementa\u00e7\u00f5es: as r\u00e9plicas recebem conjuntos de n\u00facleos id\u00eanticos; caso contr\u00e1rio, os valores medidos afastam-se entre as inst\u00e2ncias.<\/p>\n\n<h2>Cgrupos, equidade e isolamento<\/h2>\n\n<p>A afinidade, por si s\u00f3, n\u00e3o garante <strong>Equidade<\/strong>, e \u00e9 por isso que eu os combino com cgroups. O cpu.shares prioriza os grupos relativamente, o cpu.max define limites m\u00e1ximos r\u00edgidos por fatia de tempo. \u00c9 assim que eu mantenho os vizinhos barulhentos sob controle, mesmo que eles estejam rodando com CPU limitada. No alojamento multi-tenant, protejo os servi\u00e7os cr\u00edticos com quotas mais elevadas. Em conjunto, isto cria uma clara <strong>Separa\u00e7\u00e3o<\/strong> sem riscos excessivos.<\/p>\n\n<h2>Gest\u00e3o de energia e frequ\u00eancia para lat\u00eancias previs\u00edveis<\/h2>\n<p>Os estados de energia t\u00eam uma influ\u00eancia not\u00e1vel no jitter. Para objectivos rigorosos do p99, mantenho as frequ\u00eancias de base elevadas est\u00e1veis em n\u00facleos quentes (desempenho do governador ou <em>prefer\u00eancia_de_desempenho_energ\u00e9tico<\/em>) e limitar os estados C profundos para que os tempos de despertar n\u00e3o sejam dominantes. Eu uso o Turbo com modera\u00e7\u00e3o: as threads individuais beneficiam, mas os limites t\u00e9rmicos podem causar o funcionamento paralelo <strong>n\u00facleos<\/strong> acelerador. Para obter uma taxa de transfer\u00eancia uniforme, defino limites de frequ\u00eancia superior\/inferior por soquete e transfiro a l\u00f3gica de economia de energia para n\u00facleos frios. Isso reduz a varia\u00e7\u00e3o sem restringir excessivamente a taxa de transfer\u00eancia geral.<\/p>\n\n<h2>systemd, taskset e Windows: Implementa\u00e7\u00e3o<\/h2>\n\n<p>Para servi\u00e7os permanentes, utilizo <strong>systemd<\/strong> com CPUAffinity=0-3 na unidade, combinado com CPUSchedulingPolicy=fifo para cargas de trabalho RT. Eu inicio trabalhos pontuais com taskset -c 4-7 para que os backups n\u00e3o entrem em caches quentes. Encapsulo os contentores atrav\u00e9s de cpuset.cpus e cgroupv2 para que os pods recebam os seus n\u00facleos fixos. No Windows, eu defino o ProcessorAffinity para um bitmask hexadecimal via PowerShell. Essas op\u00e7\u00f5es me d\u00e3o precis\u00e3o <strong>Controlo<\/strong> at\u00e9 ao limite do kernel.<\/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>Monitoriza\u00e7\u00e3o e testes: medir em vez de adivinhar<\/h2>\n\n<p>Verifico o sucesso com <strong>perfeito<\/strong> (mudan\u00e7as de contexto, migra\u00e7\u00f5es, falhas de cache) e monitorizar p95\/p99 por s\u00e9rie temporal. As repeti\u00e7\u00f5es de carga de trabalho com wrk, hey ou sysbench mostram se os outliers est\u00e3o a diminuir. Tamb\u00e9m monitorizo o tempo de roubo nas VMs e a carga de IRQ nos n\u00facleos do anfitri\u00e3o. Uma breve compara\u00e7\u00e3o A\/B sob carga de pico revela suposi\u00e7\u00f5es incorrectas. S\u00f3 quando os valores coincidem \u00e9 que congelo as regras como permanentes <strong>Pol\u00edticas<\/strong> em.<\/p>\n\n<h2>Riscos, limites e anti-padr\u00f5es<\/h2>\n\n<p>N\u00facleos de latas de fixa\u00e7\u00e3o r\u00edgida <strong>ficar seco<\/strong> quando o tr\u00e1fego flutua. Por isso, defino apenas threads cr\u00edticas e deixo as n\u00e3o cr\u00edticas no agendador. O overcommit tamb\u00e9m consome recursos se duas VMs ruidosas quiserem o mesmo n\u00facleo. Se fixar demasiado, mais tarde ir\u00e1 debater-se com hotspots e m\u00e1 utiliza\u00e7\u00e3o. Uma boa verifica\u00e7\u00e3o da realidade: este artigo sobre fixa\u00e7\u00e3o de CPU \u00e9 <a href=\"https:\/\/webhosting.de\/pt\/cpu-pinning-hosting-raramente-faz-sentido-otimizacao-ajuste\/\">Raramente \u00fatil<\/a> exige uma abordagem ponderada, com objectivos claros e conclusivos <strong>M\u00e9tricas<\/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>Casos especiais: Alta frequ\u00eancia e tempo real<\/h2>\n\n<p>Para sub-milissegundos, fa\u00e7o a liga\u00e7\u00e3o <strong>Afinidade<\/strong> com pol\u00edtica de RT, ajuste de IRQ e consist\u00eancia NUMA. Eu atribuo IRQs de rede aos seus pr\u00f3prios n\u00facleos e mantenho os threads de espa\u00e7o do utilizador afastados deles. No AMD-EPYC com topologia chiplet, asseguro caminhos curtos entre o n\u00facleo, o controlador de mem\u00f3ria e a NIC. P\u00e1ginas grandes (HugeTLB) ajudam a reduzir as taxas de falha do TLB. Estes passos reduzem significativamente a varia\u00e7\u00e3o e criam <strong>Planeamento<\/strong> com 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>Ajuste fino para pilhas populares<\/h2>\n\n<p>Em <strong>PHP-FPM<\/strong> Defino pm dynamic com pm.max_children e process_idle_timeout correspondentes para que os trabalhadores inativos sejam omitidos. O NGINX \u00e9 executado com worker_processes auto, mas eu vinculei os workers especificamente aos n\u00facleos quentes. Eu mantenho o Apache no event-MPM curto para que a fila de execu\u00e7\u00e3o n\u00e3o cres\u00e7a. Para o Node.js, eu encapsulo a carga da CPU em threads de trabalho com sua pr\u00f3pria afinidade. Isso mant\u00e9m o loop de eventos livre e responsivo <strong>r\u00e1pido<\/strong> para E\/S.<\/p>\n\n<h2>Controlo de IRQ e separa\u00e7\u00e3o de E\/S<\/h2>\n\n<p>Pino I <strong>IRQ<\/strong>-handler via smp_affinity em n\u00facleos dedicados, para que as inunda\u00e7\u00f5es de pacotes n\u00e3o desloquem as threads de aplicativos. Partilho NICs multi-fila entre v\u00e1rios n\u00facleos para corresponder \u00e0 distribui\u00e7\u00e3o RSS. Eu separo as interrup\u00e7\u00f5es de armazenamento das IRQs de rede para evitar bloqueios de cabe\u00e7a de linha. A E\/S ass\u00edncrona e os pools de threads no NGINX evitam o bloqueio de syscalls em n\u00facleos quentes. Essa separa\u00e7\u00e3o mant\u00e9m os caminhos curtos e protege <strong>Carga de pico<\/strong>.<\/p>\n\n<h2>Guia para a introdu\u00e7\u00e3o gradual<\/h2>\n\n<p>Come\u00e7o por <strong>Defini\u00e7\u00e3o de perfis<\/strong> em Real-Traffic e, em seguida, defino apenas os servi\u00e7os cr\u00edticos. Depois, verifico o p95\/p99 e as migra\u00e7\u00f5es antes de ligar outras linhas. Os Cgroups d\u00e3o-me op\u00e7\u00f5es de corre\u00e7\u00e3o sem reiniciar. Eu documento as mudan\u00e7as por host e resumo as regras em unidades systemd. S\u00f3 depois de valores medidos est\u00e1veis \u00e9 que implemento o <strong>Configura\u00e7\u00e3o<\/strong> em geral.<\/p>\n\n<h2>Opera\u00e7\u00e3o, gest\u00e3o de altera\u00e7\u00f5es e revers\u00e3o<\/h2>\n<p>Trato as regras de afinidade como c\u00f3digo. Eu versiono as unidades do systemd e as pol\u00edticas do cgroup, e as implemento <strong>encenado<\/strong> (primeiro os can\u00e1rios, depois os mais largos) e ter um caminho de regresso bem definido. Uma revers\u00e3o r\u00e1pida \u00e9 obrigat\u00f3ria se os SLOs do p99 quebrarem ou a taxa de transfer\u00eancia cair. Congelo as altera\u00e7\u00f5es antes das horas de ponta e monitorizo as taxas de migra\u00e7\u00e3o, as taxas de erro LLC e a utiliza\u00e7\u00e3o por n\u00facleo ap\u00f3s cada passo. Isto reduz os riscos operacionais e evita que \u201eboas\u201c optimiza\u00e7\u00f5es individuais gerem efeitos secund\u00e1rios indesej\u00e1veis na rede.<\/p>\n\n<h2>Efeitos de seguran\u00e7a e isolamento<\/h2>\n<p>O Affinity tamb\u00e9m ajuda com <strong>Isolamento<\/strong>Em ambientes multi-tenant, n\u00e3o partilho irm\u00e3os SMT entre clientes para minimizar a interfer\u00eancia e os canais laterais. Os servi\u00e7os sens\u00edveis s\u00e3o executados em n\u00facleos exclusivos, separados de fontes de IRQ ruidosas. As mitiga\u00e7\u00f5es do kernel contra lacunas de execu\u00e7\u00e3o especulativa aumentam os custos de troca de contexto - a fixa\u00e7\u00e3o limpa minimiza o efeito porque menos threads cruzam os limites dos blocos. Importante: Equilibrar os objectivos de seguran\u00e7a e os objectivos de desempenho; por vezes, justifica-se \u201edesligar o SMT\u201c para algumas cargas de trabalho que s\u00e3o particularmente dignas de prote\u00e7\u00e3o, enquanto as restantes continuam a beneficiar do rendimento do SMT.<\/p>\n\n<h2>KPIs, SLOs e rentabilidade<\/h2>\n<p>Eu defino <strong>antecipadamente<\/strong> KPIs claros: lat\u00eancia p95\/p99, taxa de transfer\u00eancia, cs\/req (trocas de contexto por pedido), migra\u00e7\u00f5es por segundo e taxa de falha de LLC. Os corredores de objectivos ajudam a avaliar as solu\u00e7\u00f5es de compromisso, como \u201ep99 -25% a \u22645% menos rendimento m\u00e1ximo\u201c. Ao n\u00edvel do anfitri\u00e3o, monitorizo o desequil\u00edbrio dos n\u00facleos e o tempo de inatividade, para que a fixa\u00e7\u00e3o n\u00e3o resulte em tempo de inatividade dispendioso. A afinidade faz sentido do ponto de vista econ\u00f3mico se a previsibilidade conseguida reduzir as penaliza\u00e7\u00f5es de SLO ou aumentar a densidade nos clusters, porque os buffers de reserva podem ser mais pequenos. Sem este controlo num\u00e9rico, a afinidade continua a ser uma sensa\u00e7\u00e3o instintiva - com ela, torna-se uma solu\u00e7\u00e3o resiliente <strong>Otimiza\u00e7\u00e3o<\/strong>.<\/p>\n\n<h2>Revis\u00e3o e categoriza\u00e7\u00e3o<\/h2>\n\n<p>A Affinity cumpre <strong>Servidores<\/strong> com muitos n\u00facleos, muitas vezes oferece uma quantidade incr\u00edvel de previsibilidade com pouca interven\u00e7\u00e3o. Em VMs com excesso de comprometimento ou tr\u00e1fego altamente flutuante, eu estrangulo a implanta\u00e7\u00e3o. O conhecimento do NUMA, o ajuste do IRQ e as quotas justas determinam o sucesso. Sem monitoriza\u00e7\u00e3o, a fixa\u00e7\u00e3o torna-se rapidamente um fardo; com n\u00fameros, continua a ser uma ferramenta. A abordagem selectiva vence <strong>Previsibilidade<\/strong> e utiliza o hardware de forma eficiente.<\/p>\n\n<h2>Resumo<\/h2>\n\n<p>Eu uso <strong>Afinidade com a CPU do servidor<\/strong>, para manter as threads quentes perto de seus dados, reduzir migra\u00e7\u00f5es e suavizar picos de lat\u00eancia. Em servidores web, PHP-FPM, bancos de dados e VMs, eu combino Affinity com Cgroups, ajuste de IRQ e disciplina NUMA. As op\u00e7\u00f5es do Systemd, o conjunto de tarefas e os cpusets de contentores tornam a implementa\u00e7\u00e3o adequada \u00e0 utiliza\u00e7\u00e3o quotidiana. Asseguro o efeito com medi\u00e7\u00f5es usando perf e s\u00e9ries temporais e gradualmente giro os controlos. Se utilizar a fixa\u00e7\u00e3o de forma direcionada, obt\u00e9m tempos de resposta constantes, caches limpos e um desempenho mensuravelmente superior. <strong>Rendimento<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>O Server CPU Affinity optimiza o desempenho do alojamento atrav\u00e9s da fixa\u00e7\u00e3o e afina\u00e7\u00e3o de processos. Menos lat\u00eancia, maior rendimento - dicas pr\u00e1ticas.<\/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":"470","_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\/pt\/wp-json\/wp\/v2\/posts\/18689","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/comments?post=18689"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/18689\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/18682"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=18689"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=18689"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=18689"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}