Equilíbrio NUMA no Linux: desativar ou deixar ativado?

O equilíbrio NUMA no Linux determina se o Kernel Se os acessos à memória são localizados automaticamente ou se sou eu próprio a controlar a localização de forma específica. Neste guia, mostro quando devo manter o «numa balancing» ativo e quando devo desativá-lo para Latência- Desative a segurança.

Pontos centrais

• Automático ajuda em cargas de trabalho mistas sem ajuste NUMA.
• Desativar em casos de pinning, políticas estáticas ou latência elevada.
• Despesas gerais resulta de análises, falhas e migrações.
• Configuração controlar através do Sysctl ou de parâmetros de arranque.
• Ensaios e medir em vez de adivinhar, e só depois decidir.

NUMA explicada de forma sucinta: latências e localidade

Nos sistemas NUMA, o hardware organiza a memória em vários nós, sendo que cada um dos CPUs estão geograficamente próximos. Os acessos locais demoram menos tempo do que os distantes, o que percebo imediatamente em Latência e sinto a limitação da largura de banda. Se um processo estiver a ser executado num nó, mas os dados estiverem noutro, perco microsegundos valiosos por cada acesso. É precisamente aqui que o kernel entra em ação e otimiza a Local em termos de páginas. Quem compreender a ideia de base percebe rapidamente que a proximidade entre os núcleos de processamento e os dados é o caminho direto para uma Desempenho.

Como funciona o equilíbrio automático NUMA

O kernel observa a partir de que núcleos um processo acede às páginas e executa de forma específica Dica-Faults. Desta forma, o sistema identifica qual o nó que recebe mais acessos e, em seguida, transfere as páginas adequadas para esse nó. Estas migrações reduzem os acessos remotos e aumentam o tráfego local Taxa de acerto. Vejo esse efeito especialmente em cargas de trabalho dinâmicas, nas quais os threads migram e a memória se desloca. Quem quiser aprofundar o assunto pode explorar as relações entre a proximidade da CPU e da memória através de Afinidade de CPU/memória compreender na prática.

Quando manter ativo: cargas de trabalho típicas

Deixo a função ativa quando as aplicações não possuem uma lógica NUMA própria e os processos frequentemente mudança. Os candidatos mais comuns são servidores de aplicações, bases de dados com carga variável e hosts com muitos Container. Nestas configurações, o sistema automático aproxima as páginas e os tópicos, sem que eu tenha de os fixar manualmente. Especialmente em servidores com vários sockets, a percentagem de acessos locais aumenta sensivelmente. Para os administradores com serviços heterogéneos, isto proporciona uma boa Compromisso em termos de tempo e esforço.

Quando desativar: critérios claros

Desligo o modo automático assim que percebo que estou a remar de forma consciente ou a remar com precisão Políticas defina. Se utilizar o numactl, os cgroups ou o MPOL_BIND/MPOL_PREFERRED, já existe uma decisão definitiva sobre os percursos de memória. Nesse caso, os «hint-faults» e as migrações geram um desperdício desnecessário Despesas gerais. O mesmo se aplica a cenários em tempo real ou de HFT, em que cada microsegundo conta e a previsibilidade é uma prioridade. Quem se aprofundar na escolha das regras de colocação beneficia de uma análise das opções adequadas Políticas de memória.

Compreender e medir os custos indiretos

O equilíbrio automático implica trabalho: análises, Falhas e as migrações de páginas consomem tempo de CPU. Isso quase não se nota quando os acessos remotos diminuem significativamente, mas dificilmente compensa quando o layout já está armazenado localmente. Por isso, verifico sempre o impacto real com o numastat, o perf e métricas significativas Referências. O que é interessante é a evolução ao longo dos minutos, não apenas um pico breve. Só quando os valores medidos indicarem de forma consistente que os acessos locais estão a aumentar e as latências a diminuir é que mantenho esse modo.

Configuração: Sysctl e parâmetros de arranque

Verifico o estado através de /proc ou Sysctl e, se necessário, altero-o imediatamente, sem um Reiniciar. Para testes, bastam comandos simples como os que se seguem, que executo na consola. A longo prazo, defino o valor num ficheiro sysctl, para que se mantenha após um reinício. Quem quiser definir isto já durante o arranque, pode utilizar o parâmetro do kernel numa_balancing=enable ou desativar. Registo todas as alterações e anoto em que fase do volume de trabalho as realizei.

cat /proc/sys/kernel/numa_balancing
echo 0 > /proc/sys/kernel/numa_balancing
sysctl -w kernel.numa_balancing=1
# /etc/sysctl.d/90-numa.conf
# kernel.numa_balancing = 0

Cenários de contentores e virtualização

Em hosts com muitas máquinas virtuais e contentores, a automatização Localização muitas vezes revelam os seus pontos fortes. Os processos iniciam-se e terminam, os Cgroups redistribuem a carga e o kernel mantém a memória mais próxima dos núcleos ativos. Observo isso sobretudo em grandes servidores multi-socket com vários Nós. Nos casos especiais em que é necessário fixar rigorosamente instâncias individuais, faço uma distinção clara e desativo a função automática de forma específica nesses casos. Para uma classificação mais aprofundada, vale a pena dar uma vista de olhos a exemplos práticos Otimização NUMA em modo anfitrião.

Tabela de decisão para a prática

A síntese que se segue resume cenários típicos, o impacto esperado e a minha posição clara Recomendação. Utilizo-as como ponto de partida, mas nunca as substituo por valores medidos no sistema real. Cada ambiente apresenta as suas particularidades, e só tomo decisões após obter resultados reproduzíveis Resultados com certeza. Quem procede de forma sistemática poupa tempo mais tarde na deteção de erros e no ajuste. Pequenos testes antes de uma implementação compensam quase sempre em Constança e previsibilidade.

Cenário	Efeito típico	A minha recomendação
Cargas de trabalho padrão sem otimização NUMA	Mais acessos locais, menos acessos remotos Leituras	Deixar ativo
Bases de dados com carga variável	Localização dinâmica de páginas, moderada Digitalizações	Manter ativo, testar
Tempo real estrito ou HFT	A latência de falha de cache é um problema Jitter-Objetivos	Desativar, fixar manualmente
Fixação manual através do numactl/cgroups	Veículo automático colide com objeto fixo Políticas	Desativar
Políticas de memória estáticas (MPOL_BIND, etc.)	As migrações não trazem nenhum verdadeiro Vantagem	Desativar
Ambiente de teste/análise	Boa visão da localidade e Efeitos	Manter ativo, verificar variantes

Guia para ensaios e validação

Começo com o Balancer ativado e registo os dados locais em comparação com os remotos Acessos através do Numastat. Em seguida, desativo a função e repito as medições exatamente da mesma forma. Avalio as diferenças não só em termos de valores médios, mas também em Percentis. Os testes de regressão com perfis de carga da produção fornecem os resultados mais fiáveis. Só então é que tomo a decisão definitiva em relação ao servidor, à máquina virtual ou a um determinado Serviço.

Obstáculos frequentes e mitos

Um equívoco comum é pensar que o sistema automático substitui qualquer Fixação. Isso não é verdade, pois os orçamentos de latência rígidos mal suportam falhas adicionais. Igualmente errada é a suposição de que as migrações são sempre sem custos acontecer. Especialmente no caso de layouts que, de qualquer forma, são locais, a sobrecarga tem, na maioria das vezes, um impacto mais negativo do que positivo. Quem evita os mitos e faz medições precisas toma decisões com uma precisão significativamente maior Exatidão.

Limites da automação e interações

O AutoNUMA tem um forte impacto nas páginas anónimas que um próprio processo aloca. No entanto, nem tudo pode ser migrado de forma sensata. As páginas fixadas (mlock), a memória DMA/de dispositivos, o DAX ou as áreas registadas pelo RDMA permanecem onde estão. Também as páginas partilhadas (por exemplo, bibliotecas altamente partilhadas ou a cache de páginas) proporcionam apenas benefícios limitados com a migração, uma vez que vários processos competem entre si Padrão de acesso gerar. Além disso, tenho em conta os custos de Páginas enormes transparentes (THP): a sua migração é mais dispendiosa do que no caso das páginas de 4 KiB e pode causar picos de carga. Quem tem objetivos rigorosos em termos de latência costuma combinar THP=never ou madvise com o balanceamento desativado e o pinning limpo, para evitar surpresas.

Outro aspeto é a interação com o agendador da CPU. O agendador tenta colocar os threads onde se encontram os seus dados – e o equilibrador deslocar os dados para onde os threads estão a ser executados. Ambos complementam-se, mas, em caso de carga instável, podem causar, temporariamente, Oscilações provocar. Na prática, os intervalos de análise atenuam estes efeitos; quem observar perfis de carga extremamente instáveis pode atenuar a situação através de períodos de análise mais longos ou de um «thread-pinning» mais estável.

Ajuste fino dos parâmetros de digitalização

Para além do interruptor global, existem parâmetros do kernel que me permitem ajustar com precisão a agressividade do sistema automático. Os nomes exatos podem variar ligeiramente consoante a versão do kernel, mas o objetivo mantém-se o mesmo:

• kernel.numa_balancing_scan_delay_ms: Tempo de espera após o arranque, fork ou exec, até que a primeira verificação comece.
• kernel.numa_balancing_scan_period_min_ms / _max_ms: Limites mínimo e máximo da frequência de varredura por intervalo de endereços de processo.
• kernel.numa_balancing_rate_limit_mb: Limite máximo por intervalo de tempo para migrações de páginas, com o objetivo de poupar largura de banda de memória.
• kernel.numa_balancing_scan_size_mb: Quantidade de memória que é marcada por cada passagem de varredura (se disponível).

Por precaução, em configurações em que a latência é crítica, aumentei os períodos mínimo e máximo e reduzi os limites de taxa, em vez de desligar imediatamente o modo automático. Isto proporciona frequentemente um bom equilíbrio: menos erros de indicação, menos migrações, mas ainda com reação suficiente a erros de localização reais.

Exemplos # (temporários, até ao reinício)
sysctl -w kernel.numa_balancing_scan_period_min_ms=60000
sysctl -w kernel.numa_balancing_scan_period_max_ms=240000
sysctl -w kernel.numa_balancing_rate_limit_mb=64

Métricas e diagnóstico aprofundados

Para tomar decisões fundamentadas, analiso métricas que revelam diretamente o mecanismo subjacente. Recorro regularmente a três fontes:

• numastat: Proporção de acessos locais/remotos a nível do sistema e por processo.
• /proc//numa_maps: distribuição das páginas de memória de um processo pelos nós, incluindo indicadores como «active», «file» e «anon».
• /proc/vmstat: Contadores como numa_hint_faults, numa_hint_faults_local e numa_pages_migrated indicam se o balanceador está a funcionar e se este Sucesso tem.

Visão geral do # por processo
numastat -p 

Visão detalhada do #: quais as áreas e onde se encontram?
grep -E 'anon|file' /proc//numa_maps | head

# Visão ao nível do kernel da atividade AutoNUMA
grep -E 'numa_(hint_faults|pages_migrated)' /proc/vmstat

Nos resultados, procuro identificar tendências: a percentagem de acessos locais está a aumentar de forma constante? Ao mesmo tempo, os erros de latência estão a diminuir? Nesse caso, significa que o layout está a funcionar bem. Se a percentagem de acessos locais se mantiver estável, apesar de muitas migrações, tendo a desperdiçar ciclos. Para os objetivos de latência, verifico adicionalmente os percentis 95.º e 99.º dos tempos de resposta; pequenos ganhos na média podem ser compensados por Jitter serem encobridos.

Perfis de carga de trabalho: o que costuma funcionar

A partir da experiência prática, identificaram-se alguns padrões que indicam em que situações o AutoNUMA costuma ser útil e em que situações não o é:

• Serviços JVM e servidores de aplicações: na maioria das vezes, beneficiam-se, desde que não esteja ativa uma estratégia rígida de fixação de threads nem uma lógica NUMA própria e agressiva. Alguns ambientes de execução oferecem opções NUMA; quando as utilizo de forma rigorosa, reduzo a automação ou desativo-a.
• Bases de dados relacionais: em caso de carga variável com caches mistos, o mecanismo automático funciona frequentemente bem. No entanto, se configurar o «pinning» dedicado (Worker-to-Node, buffers partilhados distribuídos de forma estrita), desativo o equilíbrio para garantir uma reprodutibilidade precisa.
• Armazenamentos em memória e caches: um conjunto de dados grande e ativo beneficia do armazenamento local. Se a instância estiver a funcionar em modo single-threaded ou com fixação estrita, evito migrações desnecessárias desativando essa funcionalidade.
• HPC/MPI e códigos científicos: Na maioria dos casos, existem regras claras de colocação e ligação (OpenMP/numactl). Neste contexto, a previsibilidade é mais importante do que a automatização – por isso, desativo o balanceamento NUMA.

Virtualização: vNUMA, pinning e migração em tempo real

Na interação entre anfitrião e hóspede, tenho em conta ambos os níveis:

• Se a topologia vNUMA no convidado corresponder à topologia NUMA física do anfitrião, o balanceador do convidado poderá tomar decisões adequadas. Se houver divergências, surgem „vizinhanças incorretas“, que o AutoNUMA apenas compensa de forma limitada.
• Se eu atribuir vCPUs de forma fixa às CPUs do anfitrião e vincular a memória do convidado a nós específicos, isso constitui uma política explícita – reduzo ou desativo o AutoNUMA a este nível da VM, para evitar migrações duplicadas.
• Após as migrações em produção, observo uma fase de estabilização: os erros «Hint-Faults» aumentam até se estabelecer um novo equilíbrio. Durante este período, prevejo margens para Latência-pontas.

Em hosts de virtualização com alta densidade, onde as instâncias são iniciadas/paradas e os Cgroups redistribuem a carga, o funcionamento automático no host continua frequentemente a ser uma vantagem líquida. Para máquinas virtuais dedicadas sensíveis a „vizinhos ruidosos“, isolo os recursos de forma clara e defino as regras de forma estática.

Valores-alvo pragmáticos e critérios de aceitação

Defino antecipadamente o que significa „bom“, para não ficar a fazer ajustes intermináveis:

• Serviços gerais: 70–85% acessos locais são frequentemente suficientes, desde que a variância se mantenha baixa.
• SLAs de latência: Objetivo >90% local, limites máximos claros para a taxa de falhas ocultas e percentil 99.º estável.
• Com grande consumo de largura de banda: as migrações não devem saturar os canais de armazenamento – ajustar os limites de taxa e os períodos em conformidade.

Documento estes limiares e analiso os testes A/B ao longo de várias fases de carga. Só tomo uma decisão quando os resultados forem repetíveis.

Lista de verificação de resolução de problemas

• Picos repentinos de latência: verificar se há correlação entre as migrações do THP e os picos no «numa_hint_faults». Medida corretiva: aumentar os períodos de varredura, definir o THP para «madvise/never» e, se necessário, desativar o «Balance».
• Pouco efeito apesar da ativação: será que os threads estão fortemente fixados ou existem políticas de memória rígidas? Nesse caso, o sistema automático entra em conflito com as configurações definidas.
• Ritmo de migração elevado, mas mesmo assim muitos acessos remotos: verificar e aumentar o limite de taxa; em alternativa, estabilizar a carga de trabalho (fixação de threads, manter as caches estáveis em termos de temperatura).
• Valores de medição pouco claros: utilizar a perspetiva por processo com o comando `numastat -p` e `/proc//numa_maps`, em vez de se basear apenas nos valores globais do sistema.

Detalhes frequentemente ignorados

• Cargas de trabalho com grande utilização da cache de páginas: o AutoNUMA tem efeito sobretudo em páginas anónimas. Quem trabalha principalmente com restrições de E/S não deve esperar milagres com o balanceamento.
• Cgroups e cpusets: o ficheiro cpuset.mems limita os nós aos quais um grupo tem acesso. Trata-se de um quadro rígido, dentro do qual o sistema automático opera.
• Inserção a quente de memória/desativação de nós: as topologias dinâmicas alteram as distâncias; após as alterações, recomenda-se realizar um novo teste e, se necessário, ajustar os parâmetros de varredura.

Brevemente resumido

Para cargas de trabalho gerais do servidor, deixo a função automática ativada, porque, sem intervenção manual, aproxima-se Dados o que leva à ativação de núcleos. Em tempo real, HFT, fixação manual ou políticas fixas, desativo-os para evitar sobrecarga e jitter. Nas fases de teste, trabalho de forma iterativa: medir, decidir, repetir validar. Mantenho a configuração simples, documento cada alteração e verifico o impacto através de indicadores fiáveis. É assim que aproveito os pontos fortes do hardware NUMA, sem Riscos assumir.