Localidade NUMA do servidor e afinidade CPU-Memória para um desempenho máximo de alojamento

Servidor NUMA A localidade e a afinidade de memória da CPU determinam a proximidade das threads em relação à sua RAM e a constância das latências nas pilhas de hospedagem. Mostrarei de forma prática como é possível obter uma taxa de transferência mensurável com reconhecimento de topologia, estratégias de afinidade e caminhos de E/S próximos ao nó e Latência visivelmente inferior.

Pontos centrais

Para uma orientação rápida, 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çar para Localidade e Affinity de forma rentável. Saliento as ligações claras entre threads, memória e E/S para que possa derivar prioridades de forma limpa e Decisões conhecer. Também identifico cenários em que o Interleave faz sentido sem diluir os seus caminhos críticos e mostro como pode demonstrar um progresso real através da monitorização e Erro são evitados. Para ambientes virtualizados, dou dicas sobre a colocação de vCPUs e vRAM para que os sistemas convidados não deslizem por vários nós e Remoto-Os acessos explodem. Por fim, traduzirei as conclusões num breve roteiro para que possa proceder de forma estruturada e dar cada passo na direção certa. mensurável seguro.

• Localidade Em primeiro lugar: manter as threads perto da sua própria RAM, evitar as remotas.
• Afinidade corrigir: Unir núcleos e memória por política.
• Topologia ler: Nós, núcleos, dispositivos PCIe por socket.
• Caminhos de E/S pacote: Acoplar NIC, NVMe e aplicação no mesmo nó.
• Feiras em vez de adivinhar: P95/P99, acesso remoto e controlo do rendimento.

Compreender a topologia NUMA

Antes de mover cargas de trabalho, leio o Topologia do servidor: quantos nós NUMA existem, quantos núcleos e quanta RAM estão ligados a cada nó. Também presto atenção a quais dispositivos PCIe - como NICs ou SSDs NVMe - estão conectados a qual soquete, pois isso determina caminhos de interrupção e acessos à memória, e quanta RAM está conectada a cada nó. Latência caracterizado. Um nó permite o acesso à memória local a uma curta distância; qualquer coisa para além disso custa tempo e largura de banda. Quanto maior for a escala da máquina com múltiplos sockets, mais o acesso remoto afecta os tempos de resposta e consome largura de banda. Rendimento. Para uma introdução compreensível à lógica de hardware, considero um compacto Nós NUMA em resumo, para ter conscientemente em conta os limites dos nós e evitar distribuições incorrectas.

Na prática, começo com um pequeno inventário topológico e documento-o de modo a poder mais tarde derivar decisões de afinidade de uma forma compreensível. Comandos úteis:

Núcleos # e atribuição NUMA
lscpu -e=CPU,Core,Socket,Node

Visão geral do hardware NUMA do #
numactl --hardware

# Atribuir dispositivos PCIe ao seu nó NUMA
lspci -nn | grep -E "Ethernet|Non-Volatile"
for d in /sys/bus/pci/devices/*; do echo -n "$d: "; cat $d/numa_node; done

O importante é que Complexo de raiz PCIe e slots de dispositivos para os soquetes. Duas portas da mesma placa de rede podem ser atribuídas a nós diferentes; isso influencia onde as filas RX/TX e os IRQs ficam melhor. O mesmo se aplica ao NVMe: os controladores modernos têm várias filas que devem ser ligadas a núcleos próximos do nó, para que o DMA não accione quaisquer saltos de nó.

Utilizar corretamente a afinidade de memória da CPU

Com a Afinidade CPU-Memória, ligo firmemente os processos às áreas centrais e aplico a atribuição de memória local tanto quanto possível, para que Tópicos não ultrapassam constantemente a borda do nó. No Linux, eu defino CPUs via systemd ou cgroups e combino isso com políticas de memória para que a RAM seja preferencialmente criada no mesmo nó e Remoto permanece minimizado. Serviços críticos - front-ends de API, caches na memória, bancos de dados - se beneficiam imediatamente porque os tempos de espera do controlador de memória são reduzidos e os acessos ao cache são mais frequentes. No entanto, os limites de fixação demasiado rígidos podem restringir o agendamento, pelo que apoio todos os ajustes com benchmarks e monitorizo os valores de P95/P99 para detetar efeitos visíveis em Utilizador-experiência. Uma introdução compacta ao Affinity no alojamento ajuda-o a começar: Consciência de afinidade e NUMA fornecer as ferramentas necessárias para uma colocação limpa.

O fator decisivo é a Princípio do primeiro contactoA memória é criada no nó que escreve na página primeiro. Portanto, inicialize grandes heaps ou buffers nos núcleos de destino do nó em que o serviço será executado posteriormente - idealmente com a política de CPU e memória já definida (por exemplo, via unidade systemd ou numactl). Se você iniciar o cold no nó 0 e depois mover as threads para o nó 1, a maioria das páginas permanecerá remota. Para heaps de grandes tempos de execução, vale a pena usar „pre-touch“ durante o bootstrap para que as páginas apodreçam localmente e então permaneçam quentes.

Consciência NUMA na pilha de alojamento

Um sistema operativo com consciência NUMA, um hipervisor adequado e aplicações com fixação de threads desenvolvem todo o seu potencial em conjunto. Potencial. O SO favorece a colocação local se existirem recursos livres no nó, enquanto o hipervisor afecta as VMs de forma a que as vCPUs e a vRAM não se afastem e Localidade é mantido. Na aplicação, separo os pools de trabalho por nó 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âncias do servidor Web numa base nó a nó para que os hotpaths permaneçam curtos e Jitter diminui. Isto aumenta a consistência e a previsibilidade sob carga, o que influencia diretamente a previsibilidade dos SLAs em euros e evita o dispendioso sobreprovisionamento.

Ao nível do Ingress, ocupo-me de Afinidade de nós das sessões, por exemplo, através de roteamento fixo ou hashing consistente (por exemplo, no IP do cliente ou nos tokens de sessão), para que os pedidos acabem por voltar ao „seu“ trabalhador e cache local do nó. Para os serviços com estado, planeio réplicas por nó e equilibro o acesso de leitura localmente; igualo os caminhos de escrita através de replicação assíncrona ou batching para evitar ping-pong entre nós.

Programar serviços nó a nó

Agrupo as camadas de uma pilha de forma a que cada camada tenha uma referência de nó clara e Caminhos ficar curto. Uma separação clássica: web/API por nó, app worker ao lado, mais o cache local; o banco de dados também fica perto do nó se o espaço de RAM couber e IO-path não é interrompido. Desloco trabalhos de relatório, cópias de segurança ou trabalhadores em lote para nós menos críticos, de modo a que os pedidos interactivos não sejam afectados. Evito grandes instâncias monolíticas porque elas frequentemente cruzam os limites dos nós e, portanto, geram carga remota, que Desempenho desfocado. As instâncias mais pequenas e replicadas por nó proporcionam frequentemente um melhor débito na utilização quotidiana, uma vez que respeitam as regras NUMA e suavizam os picos.

Para o planeamento da capacidade, calculo espaço livre separadamente para cada nó: buffer de CPU para bursts, buffer de RAM contra OOM e margens separadas para cache de página. Desta forma, evito que o kernel troque remotamente de forma não intencional. Defino caminhos de comutação claros para o failover: se um nó falhar, as instâncias de substituição podem ser executadas entre nós, mas eu limito sua concorrência até que o nó original seja restaurado - isso mantém a latência geral estável.

Definir a afinidade da CPU: Métodos e armadilhas

Para alocação de núcleos, eu uso systemd com CPUAffinity ou cgroups com cpuset.cpus, para que os serviços tenham Áreas principais receber. Quando faço o pinning, presto atenção aos pares de hyper-threading, porque dois threads lógicos de uma unidade física partilham recursos e podem tornar-se mais lentos um ao outro se os combinar de forma infeliz, e Dicas criar. Os caminhos de latência - terminação TLS, entrada de API, leitores de cache - obtêm núcleos exclusivos, enquanto os registos, a compressão ou as cópias de segurança são movidos para outros pools. Os pools que são muito estreitos sem buffers causam filas, então eu considero o espaço livre e verifico as trocas de contexto, o comprimento da fila de execução e IRQ-distribuição. A partir da observação, deduzo se abro mais os núcleos ou se os concentro mais até que a distribuição de latência caia de forma limpa e os picos de P99 se tornem mais silenciosos.

Para reduzir ainda mais o jitter, defino seletivamente os switches do kernel, como nohz_full e rcu_nocbs para núcleos de latência exclusiva, isole-os dos serviços do sistema e coloque deliberadamente IRQs apenas em CPUs destinadas a esse fim. Utilizo o serviço „irqbalance“ 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ção e apenas com limites Be para evitar inversão de prioridade ou inanição.

Políticas de memória e máscaras NUMA

Em termos de política de memória, diferencio entre alocação local preferencial, intercalação entre vários nós e máscaras NUMA fixas via cpuset.mems, de modo que RAM flui para o local onde as threads estão efetivamente em execução. Para serviços interactivos, normalmente defino „preferred“, o que significa que o sistema atribui localmente e só se desvia quando há falta de espaço, o que é Remoto-Os acessos são limitados. Os trabalhos analíticos ou de streaming beneficiam por vezes da intercalação porque a largura de banda é distribuída pelos nós e a pressão sobre um controlador é reduzida. As máscaras fixas oferecem controlo, mas exigem disciplina no planeamento da capacidade para que não haja eventos OOM indesejados num nó que suba e Serviços interferir. O quadro seguinte categoriza as políticas comuns em cenários típicos e ajuda-o a tomar uma decisão rápida.

Política	Efeito	Cargas de trabalho típicas	Risco
Preferido (local)	RAM principalmente no nó local, opção de recurso em caso de escassez	Web/API, caches, bases de dados OLTP	Ligeiro desvio a plena carga noutros nós
Intercalar	Distribuição uniforme pelos nós selecionados	Transmissão em fluxo contínuo, análise, digitalizações de grande dimensão	Maior latência para acessos individuais
Máscara NUMA fixa	Ligação estrita aos nós de memória definidos	Serviços estritamente encapsulados, testes determinísticos	Risco de OOM se o orçamento for incorretamente planeado

Manter um olho nos interruptores de todo o sistema: modo_reclamação_de_zona influencia se um nó limpa agressivamente a sua própria memória antes de a atribuir remotamente - frequentemente indesejável para caminhos de latência. Páginas enormes transparentes (THP) pode despoletar a migração de páginas ou gerar bloqueios; para serviços sensíveis à latência, normalmente escolho „madvise“ e utilizo hugepages estáticas onde faz sentido, de modo a que os acessos TLB aumentem e os picos de falhas de página diminuam.

Ligar caminhos de rede e de E/S próximos do nó

Alinho as filas das placas de rede (RX/TX) de modo a que os seus IRQs apontem para os núcleos do nó adequado e o processamento de pacotes ocorra onde o App computação. O mesmo se aplica aos SSDs NVMe ou aos controladores RAID: os threads de E/S devem ser executados no nó ao qual o dispositivo está ligado através de PCIe, para que os caminhos de DMA permaneçam curtos e o dispositivo possa ser utilizado de forma mais eficiente. Estrangulamentos não se concretizam. No Linux, eu ajusto as máscaras de afinidade de IRQ e as vinculo aos pools de CPU dos meus serviços para criar um caminho contínuo. Com microbursts da rede, como muitos handshakes TLS, essa proximidade compensa diretamente porque os caminhos de cópia são mais curtos e os caches da CPU permanecem quentes e Contexto com menos frequência. Isto resulta num fluxo de dados consistente do pacote para a aplicação e para a memória, sem saltos de nó desnecessários.

Alavancas concretas na pilha de rede: RSS para distribuição de hardware para filas de espera, RPS/RFS para controlo da CPU baseado em software e XPS para seleção de TX. Utilizo o ethtool para atribuir filas de RX a grupos de núcleos que são executados no mesmo nó que os seus trabalhadores. Para armazenamento, uso blk-mq-ajuste e mapeamento de filas por nó; os controladores NVMe oferecem várias filas de envio/conclusão, que eu dimensiono e afinizo ≤ número de núcleos por nó. Verifique regularmente se as interrupções (cat /proc/interrupts) estão a disparar onde os núcleos da sua aplicação estão localizados - pode reconhecer a deriva aumentando os bytes remotos apesar de uma carga estável.

Estruturar a arquitetura da aplicação em conformidade com a NUMA

Ao nível da aplicação, configuro os meus próprios pools de trabalho para cada nó NUMA, mantenho as filas locais e evito hotspots de bloqueio global para que Tópicos e não saltar para trás e para a frente. Configurei a fragmentação de sessões e dados para que as partições quentes permaneçam onde os trabalhadores solicitantes estão em execução e Tempo não se perde no tráfego entre nós. Para caches, eu costumo usar réplicas em vez de uma instância central para que os leitores atinjam cópias locais do nó. Nos clientes Netty, Tokio, libuv ou DB, eu fixo loops de eventos em núcleos fixos e presto atenção à proximidade de IRQs para que as mudanças de tarefas permaneçam limitadas e Caches bater melhor. Esta disposição reduz os efeitos de ping-pong e torna os tempos de resposta mais consistentes ao longo do dia.

Uma alavanca subestimada é Alocador e opções de tempo de execução: Os alocadores habilitados para NUMA (jemalloc/tcmalloc) reduzem a contenção entre threads e mantêm as páginas mais próximas dos kernels de origem das threads. Nas pilhas da JVM, opções como NUMA awareness e pre-touch ajudam a obter fases de falha determinísticas; em .NET, alinho as threads de GC perto dos nós e presto atenção ao GC do servidor para suavizar os tempos de paragem. Em Go, dimensiono o GOMAXPROCS por pool de nós e mantenho os agendadores de goroutine longe dos núcleos de latência que trabalham perto do IRQ.

Controlo sensível do auto-equilíbrio NUMA

Os mecanismos automáticos de balanceamento NUMA do kernel podem ajudar a suavizar a carga distribuída, mas eu sempre verifico se eles podem suportar meu Afinidade são prejudicados. Nos serviços críticos em termos de latência, desativo ou reduzo o movimento automático se este retirar as threads da sua memória local e Dicas gerado. Para trabalhos analíticos ou processamento em lote amplo, tenho a tendência de deixar o balanceamento ligado porque ele pode aumentar a largura de banda sem degradar a interação. Uma introdução prática às estratégias de balanceamento fornece-me pontos de partida adicionais: Compreender o balanceamento NUMA mostra quando o sistema automático deve ser utilizado e quando deve ser atribuído manualmente. No final, tomo uma decisão baseada em dados para cada classe de serviço em vez de adotar cegamente uma predefinição global e Objectivos a perder.

Quando o balanceamento é ativado, monitorizo as taxas de migração, os picos de falhas menores/maiores e o roubo de CPU por nó. Se as páginas são movidas para frente e para trás ciclicamente, eu combato isso com uma fixação mais rígida, pré-toque e máscaras de memória 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ência interativa seja afetado.

Monitorização: medir, comparar, decidir

Sem medições, a afinação continua a ser um jogo de adivinhação, pelo que monitorizo a carga da CPU por núcleo e por nó, a utilização da memória por nó e a proporção de Remoto-acessos. Para a experiência do utilizador, as latências P95/P99 contam muito mais do que os valores médios, porque os valores atípicos caracterizam a impressão do SLA e Custos para cima. Executo perfis de carga realistas com caches frias e quentes porque ambos os mundos mostram diferentes estrangulamentos. Depois de cada alteração, documento as configurações, a data do teste e os resultados para poder reverter as modificações com segurança mais tarde e Conhecimento não se perde. Se também correlacionar as métricas da aplicação - comprimentos de fila, novas tentativas, recolha de lixo - com os valores do sistema, pode reconhecer a causa e o efeito mais rapidamente.

Ajuda prática na análise:

• numastat (relacionado com o sistema e com o processo) para o local vs. Remoto-Hit
• /proc/interrupções e tempo SoftIRQ após a CPU para desvio de IRQ
• eventos perfeitos e estatísticas do programador para profundidade da fila de espera, mudanças de contexto, faltas LLC, etc.
• fio/iperf/wrk com grupos de trabalhadores específicos de nós para comparações reprodutíveis

A avaliação é feita por nó: Espero que os histogramas de latência estejam próximos uns dos outros. Se um nó se desloca para cima, procuro primeiro uma carga de IRQ incorretamente distribuída, um desvio na cache de páginas ou heaps que foram atribuídos ao nó errado durante o aquecimento.

NUMA em VMs e contentores

Na virtualização, a colocação de vCPUs e vRAM num nó partilhado é importante para que as cargas de trabalho dos convidados não se desgastem e Latência puxa para cima. Dimensiono a RAM para que caiba no nó local e evito VMs grandes que se estendem por vários nós e Deriva gatilho. Para contêineres, uso controladores de cpuset para que os grupos de pods funcionem consistentemente em um nó e o armazenamento seja criado localmente. Eu prefiro colocar os convidados com muita E/S no nó com uma conexão direta de armazenamento para manter os caminhos de DMA curtos e IRQ-reduzir o ruído. Isto significa que mesmo os anfitriões de virtualização densos permanecem previsíveis e realizam mais projectos com o mesmo hardware.

Presto atenção a vNUMA-Exposição: O convidado deve ver a mesma estrutura de nó que o hipervisor fornece fisicamente. A fixação da vCPU e a vinculação da vRAM devem estar juntas; Eu movo hot-adds durante as janelas de manutenção, se possível, porque, caso contrário, novas páginas acabam remotamente. No Kubernetes, defino a QoS „garantida“, o gerenciador de CPU „estático“ e o posicionamento com reconhecimento de topologia para que os pods não se movam entre os nós. Para SR-IOV/VFs, atribuo VFs ao nó físico apropriado e vinculo as filas de IRQ aos conjuntos de CPU dos pods ou VMs que eles servem.

Preparação orientada para o primeiro toque, aquecimento e montes

Muitos erros de desempenho ocorrem durante InícioOs heaps crescem na fase de aquecimento, onde os primeiros pedidos chegam - muitas vezes no centro de um nó. Por isso, executo aquecimentos controlados para cada nó: inicio instâncias com uma máscara de CPU/memória definida, executo consultas de pré-carregamento direcionadas e inicializo caches em paralelo para cada nó. Para os serviços JVM, ativo o pré-touch do heap; para as bases de dados, segmento as pools de buffers nó a nó. Isto reduz as migrações de páginas subsequentes e garante que os primeiros pedidos não caracterizam aleatoriamente a distribuição da memória.

Ajuste do kernel/BIOS para latências constantes

Sob o capot, ajusto a potência e a política de interrupções:

• Definir o regulador da CPU para „desempenho“, limitar os estados C profundos, utilizar cuidadosamente os estados C dos pacotes para Jitter para reduzir.
• Não reduzir a frequência da memória; os perfis energéticos equilibrados minimizam frequentemente Rendimento sob carga.
• Evitar o espetro alargado/modulação de relógio se a consistência for mais importante do que a poupança mínima de energia.

Ao nível do kernel, mantenho as CPUs de manutenção separadas dos núcleos de latência, minimizo as interrupções do temporizador nos núcleos quentes (nohz_full) e estaciono o trabalho em segundo plano (compactação, Kswapd) de preferência nos núcleos do sistema de um nó que não executa caminhos de latência.

Resolução de problemas e antipadrões típicos

• SintomaA latência do P99 aumenta após as implementações. CausaHeaps/Caches primeiro toque no nó errado. SoluçãoAquecimento/pré-toque sob afinidade alvo, depois abrir o distribuidor de carga.
• SintomaTempo de SoftIRQ elevado em CPUs „erradas“. Causairqbalance distribuído pelos nós. SoluçãoCorrigir a afinidade IRQ, definir RPS/RFS/XPS compatível com o nó.
• SintomaOOM num nó, embora a RAM do sistema esteja livre. CausaMáscara NUMA estrita sem buffer. SoluçãoCorrigir a capacidade ou utilizar „preferencialmente“, estabelecer alertas por nó.
• SintomaTaxa de transferência irregular com NVMe. CausaMapeamento de filas incorreto, filas partilhadas entre nós. Solução: filas blk-mq/NVMe por nó, threads de E/S fixadas.

Lista de verificação prática

• Registar a topologia: Nós, núcleos, RAM, dispositivos PCIe por socket.
• Desenhar a secção de serviço: Que caminhos são Latência-crítico, que lote?
• Definir a afinidade CPU/memória para cada classe; anotar o primeiro toque no início.
• Ligar IRQ/filas perto do nó; verificar RSS/RPS/XPS e filas NVMe.
• Monitorização em P95/P99, acesso remoto, fila de execução, distribuição de IRQ.
• Controlar especificamente o equilíbrio automático; selecionar adequadamente o modo THP/zone_reclaim_mode.
• Mantenha a vNUMA, a fixação da vCPU e a vinculação da vRAM consistentes nas VMs/contêineres.
• Testar iterativamente, documentar, reverter em caso de desvio e afinar.

Breve resumo e calendário de afinação

É o que traz maior retorno, Tópicos e memória juntos, encurtar os caminhos de E/S e distribuí-los com cuidado. Começo com a análise da topologia, planeio os serviços nó a nó, defino a afinidade da CPU e da memória, ligo a rede/armazenamento de forma adequada e monitorizo os valores de P95/P99 com foco em Remoto-acessos. Em seguida, ajusto os tamanhos do pool, as máscaras de IRQ e as políticas até que os picos de latência diminuam e a taxa de transferência aumente. Para VMs e contentores, verifico a colocação separadamente porque o hipervisor tem muita influência e Limites funcionam de forma diferente. Se repetir e documentar este processo, obterá um desempenho mensurável superior da Localidade NUMA do servidor e da Afinidade CPU-Memória - muitas vezes mais barato do que atualizar hardware adicional em euros.