{"id":19865,"date":"2026-06-10T11:53:56","date_gmt":"2026-06-10T09:53:56","guid":{"rendered":"https:\/\/webhosting.de\/server-numa-locality-cpu-memory-affinity-optimierung-core\/"},"modified":"2026-06-10T11:53:56","modified_gmt":"2026-06-10T09:53:56","slug":"servidor-numa-localidade-cpu-memoria-afinidade-otimizacao-nucleo","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/server-numa-locality-cpu-memory-affinity-optimierung-core\/","title":{"rendered":"Localidade NUMA do servidor e afinidade CPU-Mem\u00f3ria para um desempenho m\u00e1ximo de alojamento"},"content":{"rendered":"<p><strong>Servidor NUMA<\/strong> A localidade e a afinidade de mem\u00f3ria da CPU determinam a proximidade das threads em rela\u00e7\u00e3o \u00e0 sua RAM e a const\u00e2ncia das lat\u00eancias nas pilhas de hospedagem. Mostrarei de forma pr\u00e1tica como \u00e9 poss\u00edvel obter uma taxa de transfer\u00eancia mensur\u00e1vel com reconhecimento de topologia, estrat\u00e9gias de afinidade e caminhos de E\/S pr\u00f3ximos ao n\u00f3 e <strong>Lat\u00eancia<\/strong> visivelmente inferior.<\/p>\n\n<h2>Pontos centrais<\/h2>\n\n<p>Para uma orienta\u00e7\u00e3o r\u00e1pida, resumo as mensagens-chave antes de explicar as etapas em pormenor e de as apoiar com exemplos, para que possa ver imediatamente por onde deve come\u00e7ar para <strong>Localidade<\/strong> e Affinity de forma rent\u00e1vel. Saliento as liga\u00e7\u00f5es claras entre threads, mem\u00f3ria e E\/S para que possa derivar prioridades de forma limpa e <strong>Decis\u00f5es<\/strong> conhecer. Tamb\u00e9m identifico cen\u00e1rios em que o Interleave faz sentido sem diluir os seus caminhos cr\u00edticos e mostro como pode demonstrar um progresso real atrav\u00e9s da monitoriza\u00e7\u00e3o e <strong>Erro<\/strong> s\u00e3o evitados. Para ambientes virtualizados, dou dicas sobre a coloca\u00e7\u00e3o de vCPUs e vRAM para que os sistemas convidados n\u00e3o deslizem por v\u00e1rios n\u00f3s e <strong>Remoto<\/strong>-Os acessos explodem. Por fim, traduzirei as conclus\u00f5es num breve roteiro para que possa proceder de forma estruturada e dar cada passo na dire\u00e7\u00e3o certa. <strong>mensur\u00e1vel<\/strong> seguro.<\/p>\n<ul>\n  <li><strong>Localidade<\/strong> Em primeiro lugar: manter as threads perto da sua pr\u00f3pria RAM, evitar as remotas.<\/li>\n  <li><strong>Afinidade<\/strong> corrigir: Unir n\u00facleos e mem\u00f3ria por pol\u00edtica.<\/li>\n  <li><strong>Topologia<\/strong> ler: N\u00f3s, n\u00facleos, dispositivos PCIe por socket.<\/li>\n  <li><strong>Caminhos de E\/S<\/strong> pacote: Acoplar NIC, NVMe e aplica\u00e7\u00e3o no mesmo n\u00f3.<\/li>\n  <li><strong>Feiras<\/strong> em vez de adivinhar: P95\/P99, acesso remoto e controlo do rendimento.<\/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\/06\/serverraum-performance-1573.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Compreender a topologia NUMA<\/h2>\n\n<p>Antes de mover cargas de trabalho, leio o <strong>Topologia<\/strong> do servidor: quantos n\u00f3s NUMA existem, quantos n\u00facleos e quanta RAM est\u00e3o ligados a cada n\u00f3. Tamb\u00e9m presto aten\u00e7\u00e3o a quais dispositivos PCIe - como NICs ou SSDs NVMe - est\u00e3o conectados a qual soquete, pois isso determina caminhos de interrup\u00e7\u00e3o e acessos \u00e0 mem\u00f3ria, e quanta RAM est\u00e1 conectada a cada n\u00f3. <strong>Lat\u00eancia<\/strong> caracterizado. Um n\u00f3 permite o acesso \u00e0 mem\u00f3ria local a uma curta dist\u00e2ncia; qualquer coisa para al\u00e9m disso custa tempo e largura de banda. Quanto maior for a escala da m\u00e1quina com m\u00faltiplos sockets, mais o acesso remoto afecta os tempos de resposta e consome largura de banda. <strong>Rendimento<\/strong>. Para uma introdu\u00e7\u00e3o compreens\u00edvel \u00e0 l\u00f3gica de hardware, considero um compacto <a href=\"https:\/\/webhosting.de\/pt\/numa-nodes-alojamento-de-servidores-grandes-sistemas-serverboost\/\">N\u00f3s NUMA em resumo<\/a>, para ter conscientemente em conta os limites dos n\u00f3s e evitar distribui\u00e7\u00f5es incorrectas.<\/p>\n\n<p>Na pr\u00e1tica, come\u00e7o com um pequeno invent\u00e1rio topol\u00f3gico e documento-o de modo a poder mais tarde derivar decis\u00f5es de afinidade de uma forma compreens\u00edvel. Comandos \u00fateis:<\/p>\n<pre><code>N\u00facleos # e atribui\u00e7\u00e3o NUMA\nlscpu -e=CPU,Core,Socket,Node\n\nVis\u00e3o geral do hardware NUMA do #\nnumactl --hardware\n\n# Atribuir dispositivos PCIe ao seu n\u00f3 NUMA\nlspci -nn | grep -E \"Ethernet|Non-Volatile\"\nfor d in \/sys\/bus\/pci\/devices\/*; do echo -n \"$d: \"; cat $d\/numa_node; done\n<\/code><\/pre>\n<p>O importante \u00e9 que <strong>Complexo de raiz PCIe<\/strong> e slots de dispositivos para os soquetes. Duas portas da mesma placa de rede podem ser atribu\u00eddas a n\u00f3s diferentes; isso influencia onde as filas RX\/TX e os IRQs ficam melhor. O mesmo se aplica ao NVMe: os controladores modernos t\u00eam v\u00e1rias filas que devem ser ligadas a n\u00facleos pr\u00f3ximos do n\u00f3, para que o DMA n\u00e3o accione quaisquer saltos de n\u00f3.<\/p>\n\n<h2>Utilizar corretamente a afinidade de mem\u00f3ria da CPU<\/h2>\n\n<p>Com a Afinidade CPU-Mem\u00f3ria, ligo firmemente os processos \u00e0s \u00e1reas centrais e aplico a atribui\u00e7\u00e3o de mem\u00f3ria local tanto quanto poss\u00edvel, para que <strong>T\u00f3picos<\/strong> n\u00e3o ultrapassam constantemente a borda do n\u00f3. No Linux, eu defino CPUs via systemd ou cgroups e combino isso com pol\u00edticas de mem\u00f3ria para que a RAM seja preferencialmente criada no mesmo n\u00f3 e <strong>Remoto<\/strong> permanece minimizado. Servi\u00e7os cr\u00edticos - front-ends de API, caches na mem\u00f3ria, bancos de dados - se beneficiam imediatamente porque os tempos de espera do controlador de mem\u00f3ria s\u00e3o reduzidos e os acessos ao cache s\u00e3o mais frequentes. No entanto, os limites de fixa\u00e7\u00e3o demasiado r\u00edgidos podem restringir o agendamento, pelo que apoio todos os ajustes com benchmarks e monitorizo os valores de P95\/P99 para detetar efeitos vis\u00edveis em <strong>Utilizador<\/strong>-experi\u00eancia. Uma introdu\u00e7\u00e3o compacta ao Affinity no alojamento ajuda-o a come\u00e7ar: <a href=\"https:\/\/webhosting.de\/pt\/servidor-processo-afinidade-numa-sensibilizacao-alojamento-ressourcentuning\/\">Consci\u00eancia de afinidade e NUMA<\/a> fornecer as ferramentas necess\u00e1rias para uma coloca\u00e7\u00e3o limpa.<\/p>\n\n<p>O fator decisivo \u00e9 a <strong>Princ\u00edpio do primeiro contacto<\/strong>A mem\u00f3ria \u00e9 criada no n\u00f3 que escreve na p\u00e1gina primeiro. Portanto, inicialize grandes heaps ou buffers nos n\u00facleos de destino do n\u00f3 em que o servi\u00e7o ser\u00e1 executado posteriormente - idealmente com a pol\u00edtica de CPU e mem\u00f3ria j\u00e1 definida (por exemplo, via unidade systemd ou numactl). Se voc\u00ea iniciar o cold no n\u00f3 0 e depois mover as threads para o n\u00f3 1, a maioria das p\u00e1ginas permanecer\u00e1 remota. Para heaps de grandes tempos de execu\u00e7\u00e3o, vale a pena usar \u201epre-touch\u201c durante o bootstrap para que as p\u00e1ginas apodre\u00e7am localmente e ent\u00e3o permane\u00e7am quentes.<\/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\/06\/server_numa_affinity_2763.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Consci\u00eancia NUMA na pilha de alojamento<\/h2>\n\n<p>Um sistema operativo com consci\u00eancia NUMA, um hipervisor adequado e aplica\u00e7\u00f5es com fixa\u00e7\u00e3o de threads desenvolvem todo o seu potencial em conjunto. <strong>Potencial<\/strong>. O SO favorece a coloca\u00e7\u00e3o local se existirem recursos livres no n\u00f3, enquanto o hipervisor afecta as VMs de forma a que as vCPUs e a vRAM n\u00e3o se afastem e <strong>Localidade<\/strong> \u00e9 mantido. Na aplica\u00e7\u00e3o, separo os pools de trabalho por n\u00f3 e mantenho as filas locais em vez de operar pools globais de forma cruzada. Organizo os processos da base de dados, os daemons de cache e as inst\u00e2ncias do servidor Web numa base n\u00f3 a n\u00f3 para que os hotpaths permane\u00e7am curtos e <strong>Jitter<\/strong> diminui. Isto aumenta a consist\u00eancia e a previsibilidade sob carga, o que influencia diretamente a previsibilidade dos SLAs em euros e evita o dispendioso sobreprovisionamento.<\/p>\n\n<p>Ao n\u00edvel do Ingress, ocupo-me de <strong>Afinidade de n\u00f3s<\/strong> das sess\u00f5es, por exemplo, atrav\u00e9s de roteamento fixo ou hashing consistente (por exemplo, no IP do cliente ou nos tokens de sess\u00e3o), para que os pedidos acabem por voltar ao \u201eseu\u201c trabalhador e cache local do n\u00f3. Para os servi\u00e7os com estado, planeio r\u00e9plicas por n\u00f3 e equilibro o acesso de leitura localmente; igualo os caminhos de escrita atrav\u00e9s de replica\u00e7\u00e3o ass\u00edncrona ou batching para evitar ping-pong entre n\u00f3s.<\/p>\n\n<h2>Programar servi\u00e7os n\u00f3 a n\u00f3<\/h2>\n\n<p>Agrupo as camadas de uma pilha de forma a que cada camada tenha uma refer\u00eancia de n\u00f3 clara e <strong>Caminhos<\/strong> ficar curto. Uma separa\u00e7\u00e3o cl\u00e1ssica: web\/API por n\u00f3, app worker ao lado, mais o cache local; o banco de dados tamb\u00e9m fica perto do n\u00f3 se o espa\u00e7o de RAM couber e <strong>IO<\/strong>-path n\u00e3o \u00e9 interrompido. Desloco trabalhos de relat\u00f3rio, c\u00f3pias de seguran\u00e7a ou trabalhadores em lote para n\u00f3s menos cr\u00edticos, de modo a que os pedidos interactivos n\u00e3o sejam afectados. Evito grandes inst\u00e2ncias monol\u00edticas porque elas frequentemente cruzam os limites dos n\u00f3s e, portanto, geram carga remota, que <strong>Desempenho<\/strong> desfocado. As inst\u00e2ncias mais pequenas e replicadas por n\u00f3 proporcionam frequentemente um melhor d\u00e9bito na utiliza\u00e7\u00e3o quotidiana, uma vez que respeitam as regras NUMA e suavizam os picos.<\/p>\n\n<p>Para o planeamento da capacidade, calculo <strong>espa\u00e7o livre<\/strong> separadamente para cada n\u00f3: buffer de CPU para bursts, buffer de RAM contra OOM e margens separadas para cache de p\u00e1gina. Desta forma, evito que o kernel troque remotamente de forma n\u00e3o intencional. Defino caminhos de comuta\u00e7\u00e3o claros para o failover: se um n\u00f3 falhar, as inst\u00e2ncias de substitui\u00e7\u00e3o podem ser executadas entre n\u00f3s, mas eu limito sua concorr\u00eancia at\u00e9 que o n\u00f3 original seja restaurado - isso mant\u00e9m a lat\u00eancia geral est\u00e1vel.<\/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\/06\/server-performance-numa-locality-4759.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Definir a afinidade da CPU: M\u00e9todos e armadilhas<\/h2>\n\n<p>Para aloca\u00e7\u00e3o de n\u00facleos, eu uso systemd com CPUAffinity ou cgroups com cpuset.cpus, para que os servi\u00e7os tenham <strong>\u00c1reas principais<\/strong> receber. Quando fa\u00e7o o pinning, presto aten\u00e7\u00e3o aos pares de hyper-threading, porque dois threads l\u00f3gicos de uma unidade f\u00edsica partilham recursos e podem tornar-se mais lentos um ao outro se os combinar de forma infeliz, e <strong>Dicas<\/strong> criar. Os caminhos de lat\u00eancia - termina\u00e7\u00e3o TLS, entrada de API, leitores de cache - obt\u00eam n\u00facleos exclusivos, enquanto os registos, a compress\u00e3o ou as c\u00f3pias de seguran\u00e7a s\u00e3o movidos para outros pools. Os pools que s\u00e3o muito estreitos sem buffers causam filas, ent\u00e3o eu considero o espa\u00e7o livre e verifico as trocas de contexto, o comprimento da fila de execu\u00e7\u00e3o e <strong>IRQ<\/strong>-distribui\u00e7\u00e3o. A partir da observa\u00e7\u00e3o, deduzo se abro mais os n\u00facleos ou se os concentro mais at\u00e9 que a distribui\u00e7\u00e3o de lat\u00eancia caia de forma limpa e os picos de P99 se tornem mais silenciosos.<\/p>\n\n<p>Para reduzir ainda mais o jitter, defino seletivamente os switches do kernel, como <strong>nohz_full<\/strong> e <strong>rcu_nocbs<\/strong> para n\u00facleos de lat\u00eancia exclusiva, isole-os dos servi\u00e7os do sistema e coloque deliberadamente IRQs apenas em CPUs destinadas a esse fim. Utilizo o servi\u00e7o \u201eirqbalance\u201c com cuidado: configure-o especificamente ou desactive-o se estiver a impedir a sua afinidade manual de IRQ. Utilizo SCHED_FIFO\/SCHED_RR com modera\u00e7\u00e3o e apenas com limites Be para evitar invers\u00e3o de prioridade ou inani\u00e7\u00e3o.<\/p>\n\n<h2>Pol\u00edticas de mem\u00f3ria e m\u00e1scaras NUMA<\/h2>\n\n<p>Em termos de pol\u00edtica de mem\u00f3ria, diferencio entre aloca\u00e7\u00e3o local preferencial, intercala\u00e7\u00e3o entre v\u00e1rios n\u00f3s e m\u00e1scaras NUMA fixas via cpuset.mems, de modo que <strong>RAM<\/strong> flui para o local onde as threads est\u00e3o efetivamente em execu\u00e7\u00e3o. Para servi\u00e7os interactivos, normalmente defino \u201epreferred\u201c, o que significa que o sistema atribui localmente e s\u00f3 se desvia quando h\u00e1 falta de espa\u00e7o, o que \u00e9 <strong>Remoto<\/strong>-Os acessos s\u00e3o limitados. Os trabalhos anal\u00edticos ou de streaming beneficiam por vezes da intercala\u00e7\u00e3o porque a largura de banda \u00e9 distribu\u00edda pelos n\u00f3s e a press\u00e3o sobre um controlador \u00e9 reduzida. As m\u00e1scaras fixas oferecem controlo, mas exigem disciplina no planeamento da capacidade para que n\u00e3o haja eventos OOM indesejados num n\u00f3 que suba e <strong>Servi\u00e7os<\/strong> interferir. O quadro seguinte categoriza as pol\u00edticas comuns em cen\u00e1rios t\u00edpicos e ajuda-o a tomar uma decis\u00e3o r\u00e1pida.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Pol\u00edtica<\/strong><\/th>\n      <th><strong>Efeito<\/strong><\/th>\n      <th><strong>Cargas de trabalho t\u00edpicas<\/strong><\/th>\n      <th><strong>Risco<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Preferido (local)<\/td>\n      <td>RAM principalmente no n\u00f3 local, op\u00e7\u00e3o de recurso em caso de escassez<\/td>\n      <td>Web\/API, caches, bases de dados OLTP<\/td>\n      <td>Ligeiro desvio a plena carga noutros n\u00f3s<\/td>\n    <\/tr>\n    <tr>\n      <td>Intercalar<\/td>\n      <td>Distribui\u00e7\u00e3o uniforme pelos n\u00f3s selecionados<\/td>\n      <td>Transmiss\u00e3o em fluxo cont\u00ednuo, an\u00e1lise, digitaliza\u00e7\u00f5es de grande dimens\u00e3o<\/td>\n      <td>Maior lat\u00eancia para acessos individuais<\/td>\n    <\/tr>\n    <tr>\n      <td>M\u00e1scara NUMA fixa<\/td>\n      <td>Liga\u00e7\u00e3o estrita aos n\u00f3s de mem\u00f3ria definidos<\/td>\n      <td>Servi\u00e7os estritamente encapsulados, testes determin\u00edsticos<\/td>\n      <td>Risco de OOM se o or\u00e7amento for incorretamente planeado<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Manter um olho nos interruptores de todo o sistema: <strong>modo_reclama\u00e7\u00e3o_de_zona<\/strong> influencia se um n\u00f3 limpa agressivamente a sua pr\u00f3pria mem\u00f3ria antes de a atribuir remotamente - frequentemente indesej\u00e1vel para caminhos de lat\u00eancia. <strong>P\u00e1ginas enormes transparentes<\/strong> (THP) pode despoletar a migra\u00e7\u00e3o de p\u00e1ginas ou gerar bloqueios; para servi\u00e7os sens\u00edveis \u00e0 lat\u00eancia, normalmente escolho \u201emadvise\u201c e utilizo hugepages est\u00e1ticas onde faz sentido, de modo a que os acessos TLB aumentem e os picos de falhas de p\u00e1gina diminuam.<\/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\/06\/server_performance_optimization_2314.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ligar caminhos de rede e de E\/S pr\u00f3ximos do n\u00f3<\/h2>\n\n<p>Alinho as filas das placas de rede (RX\/TX) de modo a que os seus IRQs apontem para os n\u00facleos do n\u00f3 adequado e o processamento de pacotes ocorra onde o <strong>App<\/strong> computa\u00e7\u00e3o. O mesmo se aplica aos SSDs NVMe ou aos controladores RAID: os threads de E\/S devem ser executados no n\u00f3 ao qual o dispositivo est\u00e1 ligado atrav\u00e9s de PCIe, para que os caminhos de DMA permane\u00e7am curtos e o dispositivo possa ser utilizado de forma mais eficiente. <strong>Estrangulamentos<\/strong> n\u00e3o se concretizam. No Linux, eu ajusto as m\u00e1scaras de afinidade de IRQ e as vinculo aos pools de CPU dos meus servi\u00e7os para criar um caminho cont\u00ednuo. Com microbursts da rede, como muitos handshakes TLS, essa proximidade compensa diretamente porque os caminhos de c\u00f3pia s\u00e3o mais curtos e os caches da CPU permanecem quentes e <strong>Contexto<\/strong> com menos frequ\u00eancia. Isto resulta num fluxo de dados consistente do pacote para a aplica\u00e7\u00e3o e para a mem\u00f3ria, sem saltos de n\u00f3 desnecess\u00e1rios.<\/p>\n\n<p>Alavancas concretas na pilha de rede: <strong>RSS<\/strong> para distribui\u00e7\u00e3o de hardware para filas de espera, <strong>RPS\/RFS<\/strong> para controlo da CPU baseado em software e <strong>XPS<\/strong> para sele\u00e7\u00e3o de TX. Utilizo o ethtool para atribuir filas de RX a grupos de n\u00facleos que s\u00e3o executados no mesmo n\u00f3 que os seus trabalhadores. Para armazenamento, uso <strong>blk-mq<\/strong>-ajuste e mapeamento de filas por n\u00f3; os controladores NVMe oferecem v\u00e1rias filas de envio\/conclus\u00e3o, que eu dimensiono e afinizo \u2264 n\u00famero de n\u00facleos por n\u00f3. Verifique regularmente se as interrup\u00e7\u00f5es (cat \/proc\/interrupts) est\u00e3o a disparar onde os n\u00facleos da sua aplica\u00e7\u00e3o est\u00e3o localizados - pode reconhecer a deriva aumentando os bytes remotos apesar de uma carga est\u00e1vel.<\/p>\n\n<h2>Estruturar a arquitetura da aplica\u00e7\u00e3o em conformidade com a NUMA<\/h2>\n\n<p>Ao n\u00edvel da aplica\u00e7\u00e3o, configuro os meus pr\u00f3prios pools de trabalho para cada n\u00f3 NUMA, mantenho as filas locais e evito hotspots de bloqueio global para que <strong>T\u00f3picos<\/strong> e n\u00e3o saltar para tr\u00e1s e para a frente. Configurei a fragmenta\u00e7\u00e3o de sess\u00f5es e dados para que as parti\u00e7\u00f5es quentes permane\u00e7am onde os trabalhadores solicitantes est\u00e3o em execu\u00e7\u00e3o e <strong>Tempo<\/strong> n\u00e3o se perde no tr\u00e1fego entre n\u00f3s. Para caches, eu costumo usar r\u00e9plicas em vez de uma inst\u00e2ncia central para que os leitores atinjam c\u00f3pias locais do n\u00f3. Nos clientes Netty, Tokio, libuv ou DB, eu fixo loops de eventos em n\u00facleos fixos e presto aten\u00e7\u00e3o \u00e0 proximidade de IRQs para que as mudan\u00e7as de tarefas permane\u00e7am limitadas e <strong>Caches<\/strong> bater melhor. Esta disposi\u00e7\u00e3o reduz os efeitos de ping-pong e torna os tempos de resposta mais consistentes ao longo do dia.<\/p>\n\n<p>Uma alavanca subestimada \u00e9 <strong>Alocador<\/strong> e op\u00e7\u00f5es de tempo de execu\u00e7\u00e3o: Os alocadores habilitados para NUMA (jemalloc\/tcmalloc) reduzem a conten\u00e7\u00e3o entre threads e mant\u00eam as p\u00e1ginas mais pr\u00f3ximas dos kernels de origem das threads. Nas pilhas da JVM, op\u00e7\u00f5es como NUMA awareness e pre-touch ajudam a obter fases de falha determin\u00edsticas; em .NET, alinho as threads de GC perto dos n\u00f3s e presto aten\u00e7\u00e3o ao GC do servidor para suavizar os tempos de paragem. Em Go, dimensiono o GOMAXPROCS por pool de n\u00f3s e mantenho os agendadores de goroutine longe dos n\u00facleos de lat\u00eancia que trabalham perto do IRQ.<\/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\/06\/server_performance_desk_7452.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Controlo sens\u00edvel do auto-equil\u00edbrio NUMA<\/h2>\n\n<p>Os mecanismos autom\u00e1ticos de balanceamento NUMA do kernel podem ajudar a suavizar a carga distribu\u00edda, mas eu sempre verifico se eles podem suportar meu <strong>Afinidade<\/strong> s\u00e3o prejudicados. Nos servi\u00e7os cr\u00edticos em termos de lat\u00eancia, desativo ou reduzo o movimento autom\u00e1tico se este retirar as threads da sua mem\u00f3ria local e <strong>Dicas<\/strong> gerado. Para trabalhos anal\u00edticos ou processamento em lote amplo, tenho a tend\u00eancia de deixar o balanceamento ligado porque ele pode aumentar a largura de banda sem degradar a intera\u00e7\u00e3o. Uma introdu\u00e7\u00e3o pr\u00e1tica \u00e0s estrat\u00e9gias de balanceamento fornece-me pontos de partida adicionais: <a href=\"https:\/\/webhosting.de\/pt\/numa-balanceamento-servidor-memoria-otimizacao-hardware-numaflux\/\">Compreender o balanceamento NUMA<\/a> mostra quando o sistema autom\u00e1tico deve ser utilizado e quando deve ser atribu\u00eddo manualmente. No final, tomo uma decis\u00e3o baseada em dados para cada classe de servi\u00e7o em vez de adotar cegamente uma predefini\u00e7\u00e3o global e <strong>Objectivos<\/strong> a perder.<\/p>\n\n<p>Quando o balanceamento \u00e9 ativado, monitorizo as taxas de migra\u00e7\u00e3o, os picos de falhas menores\/maiores e o roubo de CPU por n\u00f3. Se as p\u00e1ginas s\u00e3o movidas para frente e para tr\u00e1s ciclicamente, eu combato isso com uma fixa\u00e7\u00e3o mais r\u00edgida, pr\u00e9-toque e m\u00e1scaras de mem\u00f3ria mais estreitas. Em cargas de trabalho com varreduras longas e sequenciais, por outro lado, o balanceamento pode harmonizar a carga, desde que nenhum caminho de lat\u00eancia interativa seja afetado.<\/p>\n\n<h2>Monitoriza\u00e7\u00e3o: medir, comparar, decidir<\/h2>\n\n<p>Sem medi\u00e7\u00f5es, a afina\u00e7\u00e3o continua a ser um jogo de adivinha\u00e7\u00e3o, pelo que monitorizo a carga da CPU por n\u00facleo e por n\u00f3, a utiliza\u00e7\u00e3o da mem\u00f3ria por n\u00f3 e a propor\u00e7\u00e3o de <strong>Remoto<\/strong>-acessos. Para a experi\u00eancia do utilizador, as lat\u00eancias P95\/P99 contam muito mais do que os valores m\u00e9dios, porque os valores at\u00edpicos caracterizam a impress\u00e3o do SLA e <strong>Custos<\/strong> para cima. Executo perfis de carga realistas com caches frias e quentes porque ambos os mundos mostram diferentes estrangulamentos. Depois de cada altera\u00e7\u00e3o, documento as configura\u00e7\u00f5es, a data do teste e os resultados para poder reverter as modifica\u00e7\u00f5es com seguran\u00e7a mais tarde e <strong>Conhecimento<\/strong> n\u00e3o se perde. Se tamb\u00e9m correlacionar as m\u00e9tricas da aplica\u00e7\u00e3o - comprimentos de fila, novas tentativas, recolha de lixo - com os valores do sistema, pode reconhecer a causa e o efeito mais rapidamente.<\/p>\n\n<p>Ajuda pr\u00e1tica na an\u00e1lise:<\/p>\n<ul>\n  <li>numastat (relacionado com o sistema e com o processo) para o local vs. <strong>Remoto<\/strong>-Hit<\/li>\n  <li>\/proc\/interrup\u00e7\u00f5es e tempo SoftIRQ ap\u00f3s a CPU para desvio de IRQ<\/li>\n  <li>eventos perfeitos e estat\u00edsticas do programador para profundidade da fila de espera, mudan\u00e7as de contexto, faltas LLC, etc.<\/li>\n  <li>fio\/iperf\/wrk com grupos de trabalhadores espec\u00edficos de n\u00f3s para compara\u00e7\u00f5es reprodut\u00edveis<\/li>\n<\/ul>\n<p>A avalia\u00e7\u00e3o \u00e9 feita por n\u00f3: Espero que os histogramas de lat\u00eancia estejam pr\u00f3ximos uns dos outros. Se um n\u00f3 se desloca para cima, procuro primeiro uma carga de IRQ incorretamente distribu\u00edda, um desvio na cache de p\u00e1ginas ou heaps que foram atribu\u00eddos ao n\u00f3 errado durante o aquecimento.<\/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\/06\/hosting-serverraum-8372.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NUMA em VMs e contentores<\/h2>\n\n<p>Na virtualiza\u00e7\u00e3o, a coloca\u00e7\u00e3o de vCPUs e vRAM num n\u00f3 partilhado \u00e9 importante para que as cargas de trabalho dos convidados n\u00e3o se desgastem e <strong>Lat\u00eancia<\/strong> puxa para cima. Dimensiono a RAM para que caiba no n\u00f3 local e evito VMs grandes que se estendem por v\u00e1rios n\u00f3s e <strong>Deriva<\/strong> gatilho. Para cont\u00eaineres, uso controladores de cpuset para que os grupos de pods funcionem consistentemente em um n\u00f3 e o armazenamento seja criado localmente. Eu prefiro colocar os convidados com muita E\/S no n\u00f3 com uma conex\u00e3o direta de armazenamento para manter os caminhos de DMA curtos e <strong>IRQ<\/strong>-reduzir o ru\u00eddo. Isto significa que mesmo os anfitri\u00f5es de virtualiza\u00e7\u00e3o densos permanecem previs\u00edveis e realizam mais projectos com o mesmo hardware.<\/p>\n\n<p>Presto aten\u00e7\u00e3o a <strong>vNUMA<\/strong>-Exposi\u00e7\u00e3o: O convidado deve ver a mesma estrutura de n\u00f3 que o hipervisor fornece fisicamente. A fixa\u00e7\u00e3o da vCPU e a vincula\u00e7\u00e3o da vRAM devem estar juntas; Eu movo hot-adds durante as janelas de manuten\u00e7\u00e3o, se poss\u00edvel, porque, caso contr\u00e1rio, novas p\u00e1ginas acabam remotamente. No Kubernetes, defino a QoS \u201egarantida\u201c, o gerenciador de CPU \u201eest\u00e1tico\u201c e o posicionamento com reconhecimento de topologia para que os pods n\u00e3o se movam entre os n\u00f3s. Para SR-IOV\/VFs, atribuo VFs ao n\u00f3 f\u00edsico apropriado e vinculo as filas de IRQ aos conjuntos de CPU dos pods ou VMs que eles servem.<\/p>\n\n<h2>Prepara\u00e7\u00e3o orientada para o primeiro toque, aquecimento e montes<\/h2>\n\n<p>Muitos erros de desempenho ocorrem durante <strong>In\u00edcio<\/strong>Os heaps crescem na fase de aquecimento, onde os primeiros pedidos chegam - muitas vezes no centro de um n\u00f3. Por isso, executo aquecimentos controlados para cada n\u00f3: inicio inst\u00e2ncias com uma m\u00e1scara de CPU\/mem\u00f3ria definida, executo consultas de pr\u00e9-carregamento direcionadas e inicializo caches em paralelo para cada n\u00f3. Para os servi\u00e7os JVM, ativo o pr\u00e9-touch do heap; para as bases de dados, segmento as pools de buffers n\u00f3 a n\u00f3. Isto reduz as migra\u00e7\u00f5es de p\u00e1ginas subsequentes e garante que os primeiros pedidos n\u00e3o caracterizam aleatoriamente a distribui\u00e7\u00e3o da mem\u00f3ria.<\/p>\n\n<h2>Ajuste do kernel\/BIOS para lat\u00eancias constantes<\/h2>\n\n<p>Sob o capot, ajusto a pot\u00eancia e a pol\u00edtica de interrup\u00e7\u00f5es:<\/p>\n<ul>\n  <li>Definir o regulador da CPU para \u201edesempenho\u201c, limitar os estados C profundos, utilizar cuidadosamente os estados C dos pacotes para <strong>Jitter<\/strong> para reduzir.<\/li>\n  <li>N\u00e3o reduzir a frequ\u00eancia da mem\u00f3ria; os perfis energ\u00e9ticos equilibrados minimizam frequentemente <strong>Rendimento<\/strong> sob carga.<\/li>\n  <li>Evitar o espetro alargado\/modula\u00e7\u00e3o de rel\u00f3gio se a consist\u00eancia for mais importante do que a poupan\u00e7a m\u00ednima de energia.<\/li>\n<\/ul>\n<p>Ao n\u00edvel do kernel, mantenho as CPUs de manuten\u00e7\u00e3o separadas dos n\u00facleos de lat\u00eancia, minimizo as interrup\u00e7\u00f5es do temporizador nos n\u00facleos quentes (nohz_full) e estaciono o trabalho em segundo plano (compacta\u00e7\u00e3o, Kswapd) de prefer\u00eancia nos n\u00facleos do sistema de um n\u00f3 que n\u00e3o executa caminhos de lat\u00eancia.<\/p>\n\n<h2>Resolu\u00e7\u00e3o de problemas e antipadr\u00f5es t\u00edpicos<\/h2>\n\n<ul>\n  <li><strong>Sintoma<\/strong>A lat\u00eancia do P99 aumenta ap\u00f3s as implementa\u00e7\u00f5es. <strong>Causa<\/strong>Heaps\/Caches primeiro toque no n\u00f3 errado. <strong>Solu\u00e7\u00e3o<\/strong>Aquecimento\/pr\u00e9-toque sob afinidade alvo, depois abrir o distribuidor de carga.<\/li>\n  <li><strong>Sintoma<\/strong>Tempo de SoftIRQ elevado em CPUs \u201eerradas\u201c. <strong>Causa<\/strong>irqbalance distribu\u00eddo pelos n\u00f3s. <strong>Solu\u00e7\u00e3o<\/strong>Corrigir a afinidade IRQ, definir RPS\/RFS\/XPS compat\u00edvel com o n\u00f3.<\/li>\n  <li><strong>Sintoma<\/strong>OOM num n\u00f3, embora a RAM do sistema esteja livre. <strong>Causa<\/strong>M\u00e1scara NUMA estrita sem buffer. <strong>Solu\u00e7\u00e3o<\/strong>Corrigir a capacidade ou utilizar \u201epreferencialmente\u201c, estabelecer alertas por n\u00f3.<\/li>\n  <li><strong>Sintoma<\/strong>Taxa de transfer\u00eancia irregular com NVMe. <strong>Causa<\/strong>Mapeamento de filas incorreto, filas partilhadas entre n\u00f3s. <strong>Solu\u00e7\u00e3o<\/strong>: filas blk-mq\/NVMe por n\u00f3, threads de E\/S fixadas.<\/li>\n<\/ul>\n\n<h2>Lista de verifica\u00e7\u00e3o pr\u00e1tica<\/h2>\n\n<ul>\n  <li>Registar a topologia: N\u00f3s, n\u00facleos, RAM, dispositivos PCIe por socket.<\/li>\n  <li>Desenhar a sec\u00e7\u00e3o de servi\u00e7o: Que caminhos s\u00e3o <strong>Lat\u00eancia<\/strong>-cr\u00edtico, que lote?<\/li>\n  <li>Definir a afinidade CPU\/mem\u00f3ria para cada classe; anotar o primeiro toque no in\u00edcio.<\/li>\n  <li>Ligar IRQ\/filas perto do n\u00f3; verificar RSS\/RPS\/XPS e filas NVMe.<\/li>\n  <li>Monitoriza\u00e7\u00e3o em P95\/P99, acesso remoto, fila de execu\u00e7\u00e3o, distribui\u00e7\u00e3o de IRQ.<\/li>\n  <li>Controlar especificamente o equil\u00edbrio autom\u00e1tico; selecionar adequadamente o modo THP\/zone_reclaim_mode.<\/li>\n  <li>Mantenha a vNUMA, a fixa\u00e7\u00e3o da vCPU e a vincula\u00e7\u00e3o da vRAM consistentes nas VMs\/cont\u00eaineres.<\/li>\n  <li>Testar iterativamente, documentar, reverter em caso de desvio e afinar.<\/li>\n<\/ul>\n\n<h2>Breve resumo e calend\u00e1rio de afina\u00e7\u00e3o<\/h2>\n\n<p>\u00c9 o que traz maior retorno, <strong>T\u00f3picos<\/strong> e mem\u00f3ria juntos, encurtar os caminhos de E\/S e distribu\u00ed-los com cuidado. Come\u00e7o com a an\u00e1lise da topologia, planeio os servi\u00e7os n\u00f3 a n\u00f3, defino a afinidade da CPU e da mem\u00f3ria, ligo a rede\/armazenamento de forma adequada e monitorizo os valores de P95\/P99 com foco em <strong>Remoto<\/strong>-acessos. Em seguida, ajusto os tamanhos do pool, as m\u00e1scaras de IRQ e as pol\u00edticas at\u00e9 que os picos de lat\u00eancia diminuam e a taxa de transfer\u00eancia aumente. Para VMs e contentores, verifico a coloca\u00e7\u00e3o separadamente porque o hipervisor tem muita influ\u00eancia e <strong>Limites<\/strong> funcionam de forma diferente. Se repetir e documentar este processo, obter\u00e1 um desempenho mensur\u00e1vel superior da Localidade NUMA do servidor e da Afinidade CPU-Mem\u00f3ria - muitas vezes mais barato do que atualizar hardware adicional em euros.<\/p>","protected":false},"excerpt":{"rendered":"<p>Saiba como a Localidade NUMA do Servidor e a Afinidade CPU-Mem\u00f3ria optimizam o desempenho do seu alojamento. O guia mostra o ajuste pr\u00e1tico do desempenho para servidores modernos.<\/p>","protected":false},"author":1,"featured_media":19858,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-19865","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":"78","_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 NUMA","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":"19858","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/19865","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=19865"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/19865\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/19858"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=19865"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=19865"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=19865"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}