{"id":15663,"date":"2025-11-29T18:21:50","date_gmt":"2025-11-29T17:21:50","guid":{"rendered":"https:\/\/webhosting.de\/blog-numa-architektur-server-performance-hosting-hardware-optimierung-infrastruktur\/"},"modified":"2025-11-29T18:21:50","modified_gmt":"2025-11-29T17:21:50","slug":"blog-numa-arquitetura-servidor-desempenho-alojamento-hardware-otimizacao-infraestrutura","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/blog-numa-architektur-server-performance-hosting-hardware-optimierung-infrastruktur\/","title":{"rendered":"Arquitetura NUMA: por que ela desempenha um papel importante nos servidores modernos"},"content":{"rendered":"<p>O <strong>Arquitetura NUMA<\/strong> determina a rapidez com que os servidores modernos fornecem mem\u00f3ria aos threads e a efic\u00e1cia com que as cargas de trabalho s\u00e3o dimensionadas em caso de carga elevada. Mostro por que raz\u00e3o os acessos \u00e0 mem\u00f3ria local dominam a lat\u00eancia e a largura de banda, como os hipervisores utilizam NUMA e quais as configura\u00e7\u00f5es nas m\u00e1quinas virtuais que libertam ganhos diretos de desempenho.<\/p>\n\n<h2>Pontos centrais<\/h2>\n\n<p>Resumo brevemente as conclus\u00f5es mais importantes e destaco os fatores que t\u00eam maior impacto nos centros de dados.<\/p>\n<ul>\n  <li><strong>Mem\u00f3ria local<\/strong> minimiza a lat\u00eancia e aumenta a taxa de transfer\u00eancia<\/li>\n  <li><strong>N\u00f3 NUMA<\/strong> estruturam CPUs e RAM de forma eficiente<\/li>\n  <li><strong>Tamanho da vCPU<\/strong> Ajustar por VM ao tamanho do n\u00f3<\/li>\n  <li><strong>NUMA virtual<\/strong> passar para o sistema operativo convidado<\/li>\n  <li><strong>Regras de expans\u00e3o<\/strong> para grandes necessidades de RAM<\/li>\n<\/ul>\n<p>Eu concentro-me consistentemente em <strong>Lat\u00eancia<\/strong> e proximidade dos dados, porque \u00e9 a\u00ed que se decide o desempenho do servidor. Sockets grandes, muitos n\u00facleos e muita RAM s\u00e3o de pouca utilidade se os threads estiverem constantemente \u00e0 espera de \u00e1reas de mem\u00f3ria remotas. Dimensiono as VMs de forma a que caibam num n\u00f3 NUMA e a aloca\u00e7\u00e3o de mem\u00f3ria permane\u00e7a local. Suporto funcionalidades do hipervisor de forma seletiva, em vez de ativar tudo globalmente. Assim, garanto <strong>Escalonamento<\/strong> sem surpresas em picos de carga.<\/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\/2025\/11\/numa-serverarchitektur-4831.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>O que realmente define o NUMA<\/h2>\n\n<p>Eu penso em <strong>N\u00f3<\/strong>: Cada n\u00f3 NUMA combina n\u00facleos de CPU e uma \u00e1rea de RAM local com caminhos de acesso muito curtos. Se um thread encontrar os dados no cache L1, L2 ou L3, tudo funciona extremamente r\u00e1pido; se o conjunto de dados estiver na RAM local, a lat\u00eancia permanece baixa. No entanto, se o thread aceder a outro n\u00f3, o tempo de espera aumenta e a taxa de transfer\u00eancia diminui. S\u00e3o exatamente essas diferen\u00e7as que fazem <strong>N\u00e3o uniforme<\/strong> Acesso \u00e0 mem\u00f3ria. Por isso, organizo as cargas de trabalho de forma a que a maior parte dos acessos permane\u00e7a local.<\/p>\n\n<h2>Por que a UMA atinge os seus limites<\/h2>\n\n<p>A UMA atribui a todos os processadores um <strong>caminho de armazenamento<\/strong> o que gera congestionamento \u00e0 medida que o n\u00famero de n\u00facleos aumenta. Cada n\u00facleo adicional entra nas mesmas filas e compete pela largura de banda. Em muitas configura\u00e7\u00f5es antigas, isso causava lat\u00eancia at\u00e9 que a utiliza\u00e7\u00e3o da CPU ficava alta, mas a aplica\u00e7\u00e3o respondia lentamente. Isso parece que a \u201eCPU est\u00e1 no limite\u201c, embora o gargalo esteja, na verdade, no acesso \u00e0 mem\u00f3ria. O NUMA resolve exatamente isso. <strong>Bloqueios<\/strong> atrav\u00e9s de caminhos locais e topologia de n\u00f3s.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/11\/numa_servermeeting_4027.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NUMA vs. UMA: diferen\u00e7as em resumo<\/h2>\n\n<p>Gosto de manter as diferen\u00e7as mais importantes num resumo compacto. <strong>Tabela<\/strong> para que as decis\u00f5es sejam tomadas mais rapidamente. Esta vis\u00e3o geral mostra o que \u00e9 importante em termos de arquitetura, lat\u00eancia e escalabilidade. Ela ajuda-me a dimensionar novos hosts, bem como a localizar erros em ambientes produtivos. Quem percebe claramente a diferen\u00e7a entre acesso local e remoto toma melhores decis\u00f5es em termos de personaliza\u00e7\u00e3o de VM e aloca\u00e7\u00e3o de RAM. \u00c9 exatamente aqui que se decide a <strong>Desempenho<\/strong> sob carga.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Crit\u00e9rio<\/th>\n      <th>NUMA<\/th>\n      <th>UMA<\/th>\n      <th>Efeito pr\u00e1tico<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>acesso \u00e0 mem\u00f3ria<\/td>\n      <td>Local ou remoto<\/td>\n      <td>Normalizado<\/td>\n      <td>Os acessos locais s\u00e3o mais r\u00e1pidos; os remotos t\u00eam lat\u00eancia<\/td>\n    <\/tr>\n    <tr>\n      <td>Escalonamento<\/td>\n      <td>Muito bom com n\u00f3s<\/td>\n      <td>Limitado antecipadamente<\/td>\n      <td>Mais n\u00facleos escalam de forma mais fi\u00e1vel com NUMA<\/td>\n    <\/tr>\n    <tr>\n      <td>Topologia<\/td>\n      <td>V\u00e1rios n\u00f3s<\/td>\n      <td>Pool uniforme<\/td>\n      <td>\u00c9 necess\u00e1rio um planeamento consciente da topologia<\/td>\n    <\/tr>\n    <tr>\n      <td>hipervisor<\/td>\n      <td>Virtual NUMA dispon\u00edvel<\/td>\n      <td>Menos relevante<\/td>\n      <td>O sistema operativo convidado pode planear com reconhecimento NUMA<\/td>\n    <\/tr>\n    <tr>\n      <td>Ajuste fino<\/td>\n      <td>vCPU\/RAM por n\u00f3<\/td>\n      <td>Afina\u00e7\u00e3o global<\/td>\n      <td>As VMs adequadas aos n\u00f3s proporcionam estabilidade<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>NUMA em ambientes virtuais<\/h2>\n\n<p>Deixo o hipervisor fazer o <strong>Topologia<\/strong> para o sistema operativo convidado, para que o agendador e a gest\u00e3o de mem\u00f3ria planeiem localmente. O Virtual NUMA mostra ao convidado os limites dos seus n\u00f3s, permitindo que bancos de dados, JVMs e .NET Workers organizem seus heaps e threads de maneira mais econ\u00f4mica. Assim, evito acessos remotos caros e mantenho a lat\u00eancia est\u00e1vel. Em configura\u00e7\u00f5es sens\u00edveis, combino isso com uma estrat\u00e9gia de pinning consistente e aloca\u00e7\u00e3o fixa de RAM. Para tempos de resposta extremamente curtos, eu tamb\u00e9m uso <a href=\"https:\/\/webhosting.de\/pt\/micro-latencia-alojamento-otimizacao-banco-de-dados-rede-relampago\/\">Hospedagem com micro-lat\u00eancia<\/a> em considera\u00e7\u00e3o para reduzir ainda mais a instabilidade.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/11\/numa-architektur-servertechnik-9381.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Melhores pr\u00e1ticas para tamanhos de VM e atribui\u00e7\u00e3o de CPU<\/h2>\n\n<p>Eu dimensiono <strong>vCPUs<\/strong> de forma que uma VM caiba num n\u00f3 NUMA ou apenas o toque ligeiramente. Exemplo: se um host tiver dois n\u00f3s com 20 n\u00facleos cada, eu planeio VMs com 4 a 16 vCPUs preferencialmente dentro de um n\u00f3. Quem exceder isso corre o risco de acessos remotos e tempos de espera desnecess\u00e1rios. Distribuo a RAM da forma mais est\u00e1tica poss\u00edvel, para que o sistema operativo convidado mantenha as suas p\u00e1ginas localmente. Para cargas de trabalho com uma forte componente de thread \u00fanico, incluo a estrat\u00e9gia de n\u00facleo correta e utilizo an\u00e1lises como <a href=\"https:\/\/webhosting.de\/pt\/comparacao-de-cpus-de-alojamento-web-de-thread-unico-vs-multi-core-eficiencia-2025\/\">Thread \u00fanico vs. multi-core<\/a>.<\/p>\n\n<h2>Vantagens concretas para o hardware de alojamento<\/h2>\n\n<p>Com um planeamento NUMA adequado, aumento a <strong>densidade<\/strong> por host, sem sacrificar os tempos de resposta. Em muitos centros de dados, \u00e9 poss\u00edvel operar um n\u00famero significativamente maior de VMs por soquete, enquanto as aplica\u00e7\u00f5es respondem de forma fi\u00e1vel. A lat\u00eancia mais curta contribui diretamente para a experi\u00eancia do utilizador e para o rendimento em lote. Os custos por carga de trabalho diminuem, porque o tempo de CPU e a RAM s\u00e3o utilizados de forma mais eficiente. Quem faz uma escolha informada de hardware beneficia adicionalmente de <a href=\"https:\/\/webhosting.de\/pt\/alojamento-web-de-alto-desempenho-hardware-cpu-nvme-memoria-desempenho-servidor-turbo\/\">Hardware de alojamento web de alto desempenho<\/a> com elevada largura de banda de mem\u00f3ria.<\/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\/2025\/11\/numa_techoffice_nacht9462.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ajuste da carga de trabalho: bases de dados, caches, contentores<\/h2>\n\n<p>Certifico-me de que <strong>Bases de dados<\/strong> Mantenha os seus heaps localmente e execute os threads de trabalho no \u201eseu\u201c n\u00f3. Para motores SQL, caches na mem\u00f3ria e JVMs, vale a pena atribuir CPUs e reservar mem\u00f3ria de forma fixa. A orquestra\u00e7\u00e3o de contentores beneficia das afinidades dos n\u00f3s, para que os pods utilizem os caminhos de mem\u00f3ria mais curtos. Em caso de I\/O intenso, apostei em atribui\u00e7\u00f5es NVMe pr\u00f3ximas de NUMA, para manter os dados pr\u00f3ximos dos n\u00f3s. Assim, os hotpaths permanecem curtos e os <strong>Tempo de resposta<\/strong> amig\u00e1vel.<\/p>\n\n<h2>Monitoriza\u00e7\u00e3o e resolu\u00e7\u00e3o de problemas no NUMA<\/h2>\n\n<p>Eu me\u00e7o <strong>Lat\u00eancia<\/strong> e acessos remotos de forma direcionada, em vez de apenas observar as percentagens da CPU. As ferramentas mostram-me, por n\u00f3, quantas p\u00e1ginas est\u00e3o remotas e quais threads geram press\u00e3o na mem\u00f3ria. Se os erros remotos aumentarem, ajusto o tamanho da vCPU, as afinidades ou a aloca\u00e7\u00e3o de RAM. Se a taxa de transfer\u00eancia permanecer fraca, apesar das elevadas reservas da CPU, muitas vezes isso deve-se aos caminhos de mem\u00f3ria. Para mim, a visibilidade do ponto de vista do n\u00f3 \u00e9 o caminho mais r\u00e1pido para <strong>Causas<\/strong>, n\u00e3o apenas aos sintomas.<\/p>\n\n<h2>NUMA Spanning: utiliza\u00e7\u00e3o correta<\/h2>\n\n<p>Eu ativo <strong>Spanning<\/strong> Especificamente para VMs com requisitos de RAM muito elevados ou largura de banda excecional. A VM pode ent\u00e3o obter mem\u00f3ria atrav\u00e9s de v\u00e1rios n\u00f3s, o que torna poss\u00edvel a exist\u00eancia de inst\u00e2ncias individuais com uma pegada massiva. O pre\u00e7o a pagar \u00e9 o acesso remoto ocasional, que eu atenuo com afinidades de CPU e maior propor\u00e7\u00e3o de localidade de p\u00e1gina. Para cargas mistas, prefiro escolher v\u00e1rias VMs de tamanho m\u00e9dio em vez de uma inst\u00e2ncia muito grande. Assim, permanece <strong>Planeamento<\/strong> no dia a dia.<\/p>\n\n<h2>Licenciamento, densidade e custos reais<\/h2>\n\n<p>Eu avalio <strong>Custos<\/strong> n\u00e3o ao n\u00edvel do host, mas por carga de trabalho e por m\u00eas em euros. Quando o NUMA aumenta a densidade da VM, os custos fixos por inst\u00e2ncia diminuem e as reservas de desempenho aumentam. Isso afeta as licen\u00e7as por n\u00facleo, bem como os custos de suporte e energia. Reduzir o acesso remoto diminui o tempo de computa\u00e7\u00e3o e economiza energia na mesma tarefa. No final, o que conta \u00e9 o <strong>Balan\u00e7o global<\/strong> em euros por resultado, n\u00e3o apenas em euros por servidor.<\/p>\n\n<h2>Interprete corretamente a topologia de hardware e as interconex\u00f5es<\/h2>\n\n<p>Eu refiro-me ao f\u00edsico <strong>Topologia<\/strong> ativamente no meu planeamento. Os servidores modernos utilizam designs de CPU com v\u00e1rias partes e ligam chiplets ou dies atrav\u00e9s de interliga\u00e7\u00f5es. Isto significa que nem todos os n\u00facleos t\u00eam o mesmo caminho para cada m\u00f3dulo RAM e, mesmo dentro de um soquete, existem caminhos preferenciais. Quanto mais tr\u00e1fego passa pelas liga\u00e7\u00f5es entre soquetes, mais aumentam <strong>Lat\u00eancia<\/strong> e sobrecarga de coer\u00eancia. Por isso, verifico quantos canais de mem\u00f3ria est\u00e3o ativos por n\u00f3, se todas as ranhuras DIMM est\u00e3o equipadas simetricamente e como os n\u00f3s est\u00e3o interligados na placa-m\u00e3e. As funcionalidades Sub-NUMA, que dividem os n\u00f3s em dom\u00ednios mais pequenos, podem equalizar os pontos de acesso quando as cargas de trabalho est\u00e3o claramente segmentadas. Tamb\u00e9m observo a <strong>Topologia L3<\/strong>: Se os threads e os seus dados estiverem em dom\u00ednios de cache diferentes, a transfer\u00eancia de cache por si s\u00f3 ter\u00e1 um impacto significativo no desempenho. Um simples teste de largura de banda e uma vis\u00e3o geral da topologia mostram rapidamente se a plataforma fornece a localidade esperada ou se as interliga\u00e7\u00f5es se tornam um gargalo.<\/p>\n\n<h2>Op\u00e7\u00f5es de firmware e BIOS com efeito<\/h2>\n\n<p>No BIOS, certifico-me de que <strong>Intercala\u00e7\u00e3o de n\u00f3s<\/strong> est\u00e1 desativado, para que a estrutura NUMA permane\u00e7a vis\u00edvel. Utilizo o clustering Sub-NUMA ou modos semelhantes de forma espec\u00edfica quando as cargas de trabalho t\u00eam muitos volumes de trabalho de tamanho m\u00e9dio e claramente separados. Para obter lat\u00eancias consistentes, seleciono perfis de energia orientados para o desempenho, reduzo profundamente <strong>Estados C<\/strong> e evito o estacionamento agressivo do n\u00facleo. Otimizo a configura\u00e7\u00e3o da mem\u00f3ria para obter o m\u00e1ximo <strong>Largura de banda do canal de mem\u00f3ria<\/strong>; configura\u00e7\u00f5es DIMM assim\u00e9tricas afetam diretamente a taxa de transfer\u00eancia e o tempo de espera. Tamb\u00e9m verifico as op\u00e7\u00f5es de pr\u00e9-busca e RAS: alguns mecanismos de prote\u00e7\u00e3o aumentam a lat\u00eancia sem beneficiar a carga de trabalho. Importante: testo cada ajuste da BIOS com carga real, pois os microefeitos causados por caches e interconex\u00f5es geralmente s\u00f3 aparecem sob press\u00e3o.<\/p>\n\n<h2>Sistema operativo convidado e ajuste de tempo de execu\u00e7\u00e3o: do primeiro toque \u00e0s p\u00e1ginas enormes<\/h2>\n\n<p>No convidado, eu uso <strong>Primeiro toque<\/strong>-Aloca\u00e7\u00e3o a meu favor: os threads inicializam a \u201esua\u201c mem\u00f3ria para que as p\u00e1ginas sejam criadas localmente. No Linux, ativo ou desativo o equil\u00edbrio NUMA autom\u00e1tico de forma seletiva, dependendo da carga de trabalho; os sistemas pr\u00f3ximos a bancos de dados geralmente se beneficiam de uma liga\u00e7\u00e3o est\u00e1vel, enquanto os trabalhadores web distribu\u00eddos suportam pequenas migra\u00e7\u00f5es. Com numactl ou task-pinning, ligo servi\u00e7os a n\u00f3s e defino <strong>membind<\/strong>-Diretrizes. <strong>P\u00e1ginas enormes<\/strong> reduzo a press\u00e3o TLB; em bases de dados cr\u00edticas em termos de lat\u00eancia, prefiro p\u00e1ginas enormes est\u00e1ticas e mem\u00f3ria quente (pr\u00e9-toque) para evitar picos de falhas de p\u00e1gina. Dependendo do motor, utilizo p\u00e1ginas enormes transparentes em \u201emadvise\u201c ou desativadas, se gerarem lat\u00eancias de desfragmenta\u00e7\u00e3o. Controlo <strong>Afinidades IRQ<\/strong> e distribuo interrup\u00e7\u00f5es de rede e NVMe para os n\u00f3s adequados; RPS\/XPS e filas m\u00faltiplas ajudam a manter os caminhos de dados consistentes. No Windows, utilizo grupos de processadores e Soft-NUMA na pilha, garanto \u201eLock Pages in Memory\u201c para servi\u00e7os que exigem muita mem\u00f3ria e ativo o GC do servidor no .NET. Para JVMs, utilizo heur\u00edsticas conscientes de NUMA, pr\u00e9-touche Heaps e controlo a afinidade do thread para que GC e Worker utilizem os mesmos n\u00f3s.<\/p>\n\n<h2>Alinhar corretamente as configura\u00e7\u00f5es espec\u00edficas do hipervisor<\/h2>\n\n<p>Eu passo a <strong>Topologia vNUMA<\/strong> \u00e0 estrutura f\u00edsica. Eu seleciono os par\u00e2metros \u201eSockets\u201c, \u201eCores por Socket\u201c e \u201eThreads por Core\u201c de forma que o hipervisor n\u00e3o divida a VM por n\u00f3s. Para inst\u00e2ncias sens\u00edveis \u00e0 lat\u00eancia, eu reservo RAM para que nem o ballooning nem o swapping ocorram, e garanto recursos pCPU por meio de afinidade ou op\u00e7\u00f5es de agendador adequadas. Cuidado com a adi\u00e7\u00e3o a quente de CPU ou mem\u00f3ria: muitas plataformas desativam o vNUMA no convidado, o que resulta em acessos remotos ocultos. Eu planeio a migra\u00e7\u00e3o ao vivo de forma que os hosts de destino tenham uma topologia NUMA compat\u00edvel e dou tempo \u00e0s VMs ap\u00f3s a migra\u00e7\u00e3o para que elas <strong>Localidade da p\u00e1gina<\/strong> reconstruir (pr\u00e9-toque, aquecimento). Em ambientes KVM, utilizo as op\u00e7\u00f5es de ajuste NUMA e cpuset-Cgroups; em outros hipervisores, ferramentas como o exstop\/similares ajudam a visualizar a distribui\u00e7\u00e3o da vCPU e os acessos ao n\u00f3 em tempo real.<\/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\/2025\/11\/numa_server_workspace_8721.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>N\u00e3o desperdice a localidade PCIe e I\/O<\/h2>\n\n<p>Eu organizo <strong>NVMe<\/strong>-Unidades, HBAs e NICs ao n\u00f3 no qual os threads de computa\u00e7\u00e3o s\u00e3o executados. Eu ligo as filas SR-IOV ou vNIC aos n\u00facleos do mesmo n\u00f3 e controlo as interrup\u00e7\u00f5es de acordo. Para taxas de pacotes elevadas, escalo as filas de rece\u00e7\u00e3o\/transmiss\u00e3o e distribuo-as de forma consistente pelos n\u00facleos locais. No caso das pilhas de armazenamento, certifico-me de que os threads de trabalho para envios e conclus\u00f5es de E\/S funcionam no mesmo n\u00f3, para que o caminho dos dados n\u00e3o atravesse a interconex\u00e3o. Tamb\u00e9m planeio multipathing e RAID de software espec\u00edficos para cada n\u00f3; um caminho \u201emais curto\u201c quase sempre supera o caminho \u201emais largo\u201c com acessos externos. Assim, reduzo o jitter e trago sob carga de I\/O o <strong>tempo de CPU<\/strong> para onde ela tem efeito.<\/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\/2025\/11\/numa-serverrack-7412.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Planeamento de capacidade, sobrecompromisso e funcionalidades de mem\u00f3ria<\/h2>\n\n<p>Prefiro operar cargas de trabalho orientadas para a lat\u00eancia sem <strong>Compromisso excessivo<\/strong> na RAM e moderadamente na vCPU. Ballooning, compress\u00e3o e troca de hipervisor geram acessos externos ou picos de falha de p\u00e1gina \u2013 exatamente o que eu quero evitar. O compartilhamento transparente de p\u00e1ginas \u00e9 ineficaz em muitas configura\u00e7\u00f5es e pode obscurecer a vis\u00e3o da localidade real. Eu calibro a combina\u00e7\u00e3o das VMs de forma que v\u00e1rias inst\u00e2ncias que consomem muita largura de banda de mem\u00f3ria n\u00e3o colidam no mesmo n\u00f3. Para motores in-memory, eu planejo generosamente <strong>Reservas<\/strong> e, quando for adequado, Huge Pages no convidado, que o hipervisor pode transmitir. Assim, a taxa de acertos TLB e os tempos de acesso permanecem previs\u00edveis.<\/p>\n\n<h2>Migra\u00e7\u00e3o ao vivo e alta disponibilidade<\/h2>\n\n<p>Tenho em conta que uma <strong>Migra\u00e7\u00e3o<\/strong> destruo temporariamente a localidade lateral de uma VM. Ap\u00f3s a migra\u00e7\u00e3o, aque\u00e7o os heaps cr\u00edticos e deixo que os trabalhos em segundo plano reconstruam os hotsets. Planeio os hosts de destino com uma topologia NUMA semelhante, para que o vNUMA n\u00e3o precise ser recortado. Para casos de HA com hardware heterog\u00e9neo, defino pol\u00edticas: ou aceito uma lat\u00eancia mais elevada por um curto per\u00edodo de tempo ou priorizo hosts com tamanho de n\u00f3 compat\u00edvel. \u00c9 importante observar ap\u00f3s a migra\u00e7\u00e3o: se as propor\u00e7\u00f5es de p\u00e1ginas remotas aumentarem, ajusto as afinidades ou aciono o pr\u00e9-falha at\u00e9 que o <strong>Localidade<\/strong> novamente se encaixa.<\/p>\n\n<h2>Padr\u00f5es pr\u00e1ticos de diagn\u00f3stico<\/h2>\n\n<p>Reconhe\u00e7o os problemas t\u00edpicos do NUMA por alguns padr\u00f5es: a CPU fica \u201equente\u201c, mas o <strong>Instru\u00e7\u00f5es por ciclo<\/strong> permanecem baixos; a lat\u00eancia oscila em ondas; threads individuais bloqueiam o acesso \u00e0 mem\u00f3ria, embora os n\u00facleos estejam livres. Nesses casos, verifico os acessos remotos, a utiliza\u00e7\u00e3o da interconex\u00e3o, as falhas de TLB e a distribui\u00e7\u00e3o de threads ativos por n\u00f3. Correlaciono a carga de interrup\u00e7\u00f5es com os n\u00facleos que suportam a aplica\u00e7\u00e3o e verifico se os caches entre n\u00f3s s\u00e3o constantemente invalidados. Uma simples contraprova \u00e9 reduzir a VM para um n\u00f3: se as lat\u00eancias ca\u00edrem imediatamente, a causa foi o spanning ou o agendamento. Da mesma forma, testes dedicados revelam a largura de banda da RAM por n\u00f3 e mostram se a configura\u00e7\u00e3o DIMM ou as op\u00e7\u00f5es do BIOS est\u00e3o a causar lentid\u00e3o.<\/p>\n\n<h2>Lista de verifica\u00e7\u00e3o pr\u00e1tica<\/h2>\n\n<ul>\n  <li>Compreender a topologia: n\u00f3s, canais de mem\u00f3ria, aloca\u00e7\u00e3o PCIe, dom\u00ednios de cache<\/li>\n  <li>Verificar BIOS: Node Interleaving desativado, perfil de energia Performance, C-States flat<\/li>\n  <li>Cortar VMs: vCPUs por VM \u2264 tamanho do n\u00f3, vNUMA correto, observar Hot-Add<\/li>\n  <li>Proteger a RAM: reservas para cargas de trabalho com lat\u00eancia, p\u00e1ginas enormes quando for \u00fatil<\/li>\n  <li>Definir afinidade: ligar threads, IRQs, filas de E\/S ao mesmo n\u00f3<\/li>\n  <li>Contentores\/Pods: utilizar afinidade de n\u00f3s, gestor de CPU e consci\u00eancia topol\u00f3gica<\/li>\n  <li>Aplica\u00e7\u00e3o seletiva: acompanhar grandes inst\u00e2ncias com pol\u00edticas e monitoriza\u00e7\u00e3o<\/li>\n  <li>Planejar a migra\u00e7\u00e3o: topologia de destino adequada, pr\u00e9-toque de heaps, observar a localidade<\/li>\n  <li>Aprimorar a monitoriza\u00e7\u00e3o: acessos remotos, largura de banda por n\u00f3, utiliza\u00e7\u00e3o da interconex\u00e3o<\/li>\n  <li>Testar regularmente: verifica\u00e7\u00f5es de largura de banda\/lat\u00eancia ap\u00f3s altera\u00e7\u00f5es de firmware ou host<\/li>\n<\/ul>","protected":false},"excerpt":{"rendered":"<p>Descubra como a arquitetura NUMA est\u00e1 a revolucionar o desempenho dos servidores e por que ela \u00e9 essencial no hardware de hospedagem moderno. Conhe\u00e7a as melhores pr\u00e1ticas e dicas de otimiza\u00e7\u00e3o.<\/p>","protected":false},"author":1,"featured_media":15656,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[922],"tags":[],"class_list":["post-15663","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technologie"],"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":"2436","_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":null,"_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":"NUMA-Architektur","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":"15656","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/15663","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=15663"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/15663\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/15656"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=15663"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=15663"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=15663"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}