Saltar para o conteúdo 
Memória NUMA determina, no caso de grandes servidores de bases de dados, a proximidade com que os threads operam em relação à memória necessária e em que medida as latências influenciam os tempos de resposta e o débito. Coordeno de forma específica a alocação da CPU, a localização da memória e a dimensão da carga de trabalho, reduzo os acessos remotos e, assim, consigo uma solução fiável e previsível Desempenho.
Pontos centrais
- Topologia Compreender: ter em conta de forma específica os nós, os núcleos, a RAM e a interligação.
- Políticas Escolher a opção adequada: Strict, Preferred, Interleave, de acordo com o objetivo da carga de trabalho.
- afinidade Implementar: vincular threads, IRQs e memória localmente.
- VMs por nó: atribuir a vCPU e a RAM a um nó NUMA.
- Monitorização Executar: medir as leituras remotas, a latência P99 e a carga dos nós.
Compreender a topologia NUMA
Começo cada otimização com a Topologia: Quantos nós NUMA existem, como estão distribuídos os núcleos, como é que a RAM está ligada aos soquetes e qual é o custo dos acessos à interligação. O acesso à memória local demora significativamente menos tempo do que um acesso que ultrapasse os limites dos nós; por isso, evito acessos desnecessários Remoto-Métodos. Os grandes servidores de bases de dados beneficiam quando planeio os volumes de trabalho de forma a que os threads e os dados permaneçam no mesmo nó. Se o volume de dados ativo não couber num único nó, planeio a distribuição de forma deliberada, em vez de deixar isso a cargo do comportamento padrão. Desta forma, mantenho a Latência baixa e permite um débito constante, mesmo sob carga elevada.
Selecionar corretamente as configurações do BIOS e do hardware
Verifico no BIOS se Intercalação de nós está desativada, para que a separação NUMA seja mantida. Atribuo os canais de memória de forma simétrica por soquete e presto atenção à configuração (1DPC vs. 2DPC), para que a frequência e a largura de banda não sofram quedas desnecessárias. Funcionalidades como Estados C E, no que diz respeito aos modos de poupança de energia mais agressivos, defino os objetivos de latência de forma mais conservadora, para que os núcleos não tenham de acordar constantemente. SMT/Hyper-Threading Avalio em função da carga de trabalho específica: no caso de cargas de trabalho OLTP fortemente dependentes da memória, limito o número de threads SMT ativos em paralelo por núcleo, para reduzir a pressão sobre a cache e a variabilidade. Além disso, verifico se os dispositivos PCIe (NICs, NVMe) estão ligados localmente por soquete, para que a sua IRQs e para que os percursos DMA não atravessem a interligação. Quem abordar esta questão de forma minuciosa estabelece a base sobre a qual as políticas e as afinidades produzem os seus efeitos.
Escolher corretamente as políticas de memória
A escolha de Política determina a partir de que nó o kernel aloca memória e como funcionam os mecanismos de fallback. A opção «Strict» estabelece limites rígidos e interrompe as alocações se o nó de destino não tiver espaço disponível; isto dá prioridade a Desempenho sobre flexibilidade. A estratégia «Preferred» mantém um nó preferencial, mas, em caso de escassez, recorre a outros, oferecendo assim um meio-termo. O Interleave distribui as páginas por vários nós através do método Round-Robin, o que pode fazer sentido no caso de grandes volumes de dados com utilização uniforme. Para muitas bases de dados, uma estratégia local com Preferred ou Strict é, na maioria das vezes, a melhor opção Escolha.
| Política | Conduta | Utilização típica | Vantagens | Riscos |
|---|---|---|---|---|
| Rigoroso | Utiliza apenas a memória do nó de destino; caso contrário, ocorre um erro | Crítica latente Bases de dados com um planeamento claro dos nós | O mais local possível Acessos, latências previsíveis | A alocação pode falhar se o nó estiver cheio |
| Preferido | Nó preferencial, com possibilidade de recurso a outros | Geral Cargas de trabalho com carga variável | Boa proximidade com uma flexibilidade aceitável | Maior percentagem de trabalho à distância em caso de escassez |
| Intercalar | Round-Robin em vários nós | Muito grande, amplamente utilizada Dados | Distribuição da carga de trabalho por vários nós | Localização menos favorável, latência potencialmente mais elevada |
Threads, afinidade da CPU e ligação à memória
Fixo os threads aos núcleos do nó de destino, mapeio a memória com o numactl e alinho as IRQs de forma a que Dados manter-se local. Esta combinação de afinidade da CPU e ligação à memória reduz as dispendiosas leituras remotas e torna a distribuição do tempo de execução mais compacta. Para um controlo granular, utilizo políticas ao nível do processo ou do thread e mantenho o buffer pool o mais próximo possível dos threads de trabalho ativos. Quem quiser aprofundar o assunto encontrará passos práticos para Afinidade com a CPU, que podem ser aplicadas diretamente em servidores produtivos. É assim que garanto a consistência Latências mesmo quando o sistema está sob forte carga.
Dar prioridade aos Hotsets locais
Identifico os «hotsets» da Carga de trabalho e coloco-os estritamente a nível local, enquanto os dados pouco utilizados podem ser armazenados de forma mais flexível. Graças a esta priorização, mantenho-me próximo da RAM do nó nas rotas principais. Se a carga aumentar, a solução escala de forma eficiente, porque os caminhos mais dispendiosos continuam a ser executados localmente. Sem esta organização, a curva de latência desvia-se assim que os threads começam a aceder cada vez mais a dados em vários nós. Uma clara Encadernação impede precisamente este comportamento de forma fiável.
Unificar o NUMA de armazenamento e de rede
Eu organizo NICs e NVMe-Atribuo os dispositivos de forma específica aos soquetes e redireciono as suas IRQs para núcleos locais. Mantenho o direcionamento de receção/transmissão (RSS/RPS/XPS) consistente por nó, para que os pacotes sejam processados no mesmo local onde os threads da base de dados estão a ser executados. No caso do NVMe, utilizo várias filas por núcleo e fixo os threads de E/S localmente, para que os caminhos de registo e de dados não oscilem através da interligação. Para a replicação, separo os caminhos de rede por nó, para que os fluxos WAL/Redo recebidos cheguem localmente. Desta forma, mantêm-se IO– e os percursos da CPU são congruentes, e a base de dados não desperdiça ciclos em cópias desnecessárias através do sistema de memória.
Planear máquinas virtuais com base no tamanho dos nós
Dimensiono as máquinas virtuais de forma a que o número de vCPUs e a memória RAM se enquadrem num nó NUMA físico, pois isso reduz Latência e tráfego de interligação. As VMs de grande dimensão, que são maiores do que um nó, distribuem inevitavelmente os acessos à memória, perdendo assim a previsibilidade. Se uma VM tiver de ser maior, planeio explicitamente o vNUMA e procuro garantir uma distribuição simétrica pelos nós. No que diz respeito ao lado do anfitrião, evito a sobre-subscrição em cargas de trabalho com latência e mantenho a memória local reservada por VM. Uma visão geral rápida da estrutura física dos nós é fornecida por „Planear nós NUMA“, o que facilita a tomada de decisões sobre o tamanho da VM e Erro evita problemas na colocação.
Ter em conta as definições do hipervisor
Verifico como o hipervisor apresenta o vNUMA e mantenho a atribuição de grupos de vCPU a Núcleos consistente. Além disso, certifico-me de que a topologia NUMA da VM corresponda à do anfitrião, para que o agendador possa permanecer local. Mantenho as reservas de memória e as regras de anti-afinidade tão reduzidas quanto possível, mas tão rigorosas quanto necessário. Prefiro substituir uma elevada densidade de máquinas virtuais num único soquete por uma distribuição próxima dos nós. Assim, faço o seguinte: Remoto- Reduzir ao mínimo os acessos e manter os percursos de E/S estáveis.
Prática de contentores e orquestração
Nos recipientes, coloco cpuset-Limites consistentes: CPUs e máscaras de memória associadas (cpuset.cpus, cpuset.mems) estão interligados. As «slices» e as «units» do Systemd recebem afinidades fixas de CPU, para que o kernel aplique efetivamente a priorização de memória. Nas camadas de orquestração, pretendo utilizar pods/serviços perto do nó, utilizo avaliações de topologia e atribuição estática de CPU para que uma carga de trabalho não oscile entre nós. Declaro explicitamente as Huge Pages por pod/contentor e mantenho estáveis o seu tamanho e número por nó. Importante: atribuo os processos de infraestrutura e secundários (registo, sidecars, cópias de segurança) a outros núcleos ou mesmo ao outro nó NUMA, para não interferir com os conjuntos ativos da base de dados.
Equilíbrio NUMA e otimização do sistema operativo
O equilíbrio automático NUMA pode localizar Acessos melhorar quando as cargas de trabalho se deslocam ou quando as fases sofrem alterações significativas. Utilizo-o de forma seletiva, mas observo se a movimentação de páginas de um lado para o outro causa mais problemas do que benefícios. Os processos bem definidos, com uma afinidade clara, beneficiam frequentemente de políticas definidas manualmente, em vez de reajustes constantes. Verifico os parâmetros do kernel, o controlo de IRQ e as Huge Pages transparentes, sempre no contexto da base de dados e da plataforma. Como ponto de partida, isto ajuda-me Balanceamento NUMA-Guia para testar as configurações passo a passo e a dispersão reduzir as latências.
Utilizar as «Huge Pages» de forma seletiva
Utilizo as Huge Pages para reduzir as falhas do TLB e grandes Memóriaabordar as áreas de forma mais eficiente. Para os servidores de bases de dados, reservo as páginas antecipadamente, atribuo-as aos nós e verifico se a instância as utiliza efetivamente. Desativo frequentemente as Transparent Huge Pages quando há objetivos de latência e defino Huge Pages estáticas, para que a alocação se mantenha determinística. No entanto, a proximidade ao nó NUMA continua a ser determinante; as Huge Pages reforçam uma boa estratégia, mas não a substituem. Quem ignorar isto dificilmente obterá resultados Desempenho e corre o risco de efeitos secundários durante a paginação.
Dimensionamento de bases de dados: buffer pool e carga de trabalho
Planeio o volume de trabalho ativo de forma a que o buffer pool, as caches de bloqueios e de planos e os recursos mais solicitados Tabelas caber num nó. No caso de instâncias muito grandes, divido os serviços ou shards pelos nós, em vez de criar uma instância monolítica gigantesca que abranja todos os nós. Para casos OLTP, mantenho o buffer pool por nó compacto e dou prioridade às taxas de acerto locais. Para análises OLAP, o interleave pode fazer sentido em casos específicos, quando o volume de dados é gigantesco e uniforme. Sem esta disciplina, o Interconexão-O tráfego e consome as reservas precisamente quando ocorrem picos de carga.
Dicas específicas para bases de dados
Tenho em conta o modelo de processos e threads do motor: PostgreSQL Utiliza processos, por isso executo a instância principal, o Autovacuum e o Checkpointer separadamente em cada nó e mantenho buffers partilhados localmente por Shard. Em MySQL/InnoDB arquivo instâncias do buffer pool no nó e alinhar localmente os threads de E/S e o gravador de registos. Servidor SQL beneficia de um Soft-NUMA adaptado e de uma alocação que organiza os agendadores e os grupos de memória ao longo dos nós físicos. Oráculo-Configurei as instâncias com Large Pages locais e segmentei os servidores de trabalho e de E/S pelos nós. De um modo geral, reduzo a contenção de arena do alocador (por exemplo, jemalloc) através de arenas otimizadas para NUMA e asseguro que Gestor de Bloqueios e manter os pontos críticos de bloqueio (latch hotspots) localizados, distribuindo o particionamento e o sharding pelos nós.
Monitorização: métricas que importam
Medei as leituras remotas, o tráfego de interligação entre nós, as falhas de página por nó e o P99-Latência das consultas relevantes. Além disso, observo a utilização da CPU por nó, os rácios de falhas NUMA e a percentagem de acessos à memória local. Esta visão permite verificar se a política está a surtir efeito ou se os threads estão a aceder de forma descontrolada a páginas remotas. Estabeleço uma correlação entre os picos e as decisões do agendador, os eventos de migração e os erros de alocação. Só estas métricas confirmam que a Política não só no laboratório, mas de forma permanente no sistema produtivo.
Estratégia de teste e implementação
Faço os testes por etapas: primeiro, microbenchmarks para Largura de banda e a latência por nó; depois, cargas de trabalho realistas com caches frios e quentes. Aumento gradualmente os níveis de carga, meço os valores P95/P99/P99,9 e observo a distribuição, não apenas os valores médios. Documento cada alteração (política, afinidades, Huge Pages, redirecionamento de IRQ) e comparo A/B em condições idênticas. Antes da implementação, defino Critérios de anulação e um plano de reversão, para que, em caso de regressões, eu possa regressar rapidamente à configuração anterior. Um breve teste de estabilidade sob carga contínua permite verificar Deriva e migrações que permanecem invisíveis em períodos curtos.
Procedimento passo a passo
Primeiro, registo a Topologia: Número de nós, atribuição de núcleos, canais de memória e interligação. Em seguida, determino a carga de trabalho alvo por nó e verifico se os «hotsets» se encaixam. No passo seguinte, defino a afinidade da CPU, o direcionamento de IRQ e a ligação de memória ao nível do processo ou do thread. Em seguida, ativo ou desativo o balanceamento NUMA, dependendo da dinâmica da carga de trabalho, e, se necessário, reservo Huge Pages por nó. Por fim, verifico o resultado com testes de carga repetíveis e monitorizo Números-chave em funcionamento contínuo.
Exemplos práticos e obstáculos
Uma instância OLTP com muitas transações curtas obtém ganhos mensuráveis quando defino os threads de trabalho e o buffer pool para um Nó definir e selecionar „Strict“ ou «Preferred». Um armazém de dados com varreduras amplas pode beneficiar do «Interleave» se os dados forem utilizados de forma muito uniforme e os nós estiverem bem aproveitados. As máquinas virtuais (VMs) perdem visivelmente a previsibilidade assim que ultrapassam os limites dos nós e o hipervisor atribui memória de forma deslocada. Vejo frequentemente que uma única VM «extensa» sobrecarrega a interligação e, consequentemente, também abranda as VMs vizinhas. Estes efeitos desaparecem assim que passo para o modo local Atribuição e volte a uma configuração vNUMA mais simples.
Cenários de erro e anti-padrões
Com Rigoroso aumenta o risco de as alocações falharem e de o OOM-Killer intervir. Por isso, mantenho espaço livre no nó de destino, monitorizo as tentativas falhadas e defino planos alternativos (por exemplo, redimensionamento seletivo fora dos horários de pico). Transparent Huge Pages no sempre- O modo provoca em percursos de latência Desfragmentação e estábulos – utilizo reservas estáticas ou ativo o THP enlouquecer. O equilíbrio automático NUMA pode deslocar páginas para um lado e para o outro quando a carga oscila; se detetar padrões de «page bounce», volto a definir as políticas manualmente. Nas máquinas virtuais, Balonismo e a compressão de memória é prejudicial para a previsibilidade; desativo estas funções para bases de dados críticas. Só planeio migrações em tempo real entre nós durante janelas de inatividade ou, em alternativa, transfiro primeiro os dados a nível da base de dados, para que a interligação não fique sobrecarregada de forma secundária.
Planeamento da capacidade e crescimento
Estou a planear, por cada nó, uma Reserva Defino valores entre 10 e 20 % para picos de carga, Autovacuum/Compaction e tarefas de manutenção periódicas. Se o volume de dados aumentar, começo por escalar ao longo dos nós (shards/serviços), em vez de aumentar cegamente todo o buffer pool. Impedo o „crescimento silencioso“ através de limites rígidos por nó e de alertas, assim que as taxas de acertos locais diminuírem ou as proporções remotas aumentarem. Nas projeções para os próximos trimestres, tenho em conta não só o volume de dados, mas também Taxas de transação e alterações na distribuição do acesso, uma vez que estas alteram frequentemente os conjuntos ativos mais rapidamente do que a mera necessidade de memória. Desta forma, a plataforma mantém-se estável – e as expansões são realizadas de forma controlada, sem sacrificar a localidade NUMA.
Balanço curto
Eu otimizo grandes servidores de bases de dados ao NUMA-Combinar de forma eficaz a topologia, as políticas e a dimensão da carga de trabalho. A alocação de memória local proporciona os milissegundos decisivos, enquanto os acessos remotos não planeados aumentam a latência P99. No futuro, planeio as máquinas virtuais de forma a que se encaixem nos nós ou utilizem claramente o vNUMA. Utilizo de forma seletiva as configurações do sistema operativo, as afinidades e as Huge Pages, verifico o seu impacto e só implemento alterações com base em pontos de medição. Quem seguir estes passos alcançará o desempenho esperado Desempenho com hardware moderno e mantém as plataformas rápidas e fiáveis, mesmo sob cargas elevadas.
