Quando migramos bancos de dados de missão crítica para servidores modernos de grande porte, um erro comum é acreditar que "mais CPUs" significa automaticamente "mais performance". Na realidade, sem a configuração correta, adicionar processadores pode até piorar o desempenho do seu IBM Informix.
O grande vilão invisível em servidores multi-core modernos chama-se Latência NUMA (Non-Uniform Memory Access). Neste artigo, vamos entender como a Afinidade de CPU (CPU Affinity) no Informix pode resolver esse problema e extrair 100% do poder do seu hardware.
O Problema da Arquitetura NUMA
Em servidores com múltiplos processadores físicos (sockets), a memória RAM é dividida e conectada diretamente a cada processador. Isso cria os chamados "Nós NUMA".
Se uma thread do Informix (um Virtual Processor - VP) está rodando na CPU do Nó 0, mas precisa acessar dados que estão na memória RAM conectada ao Nó 1, ocorre o Cross-Node Memory Access. Esse tráfego passa pelo barramento de interconexão da placa-mãe, gerando latência e destruindo a performance de consultas pesadas.
Mapeando a Topologia do Servidor (Linux)
Antes de configurar o banco, precisamos entender o hardware. Vamos usar como exemplo um servidor robusto com 96 CPUs lógicas (2 sockets, 24 cores físicos por socket, com Hyper-Threading habilitado).
O primeiro passo é rodar o comando lscpu no Linux para mapear quais CPUs pertencem a quais nós NUMA:
# Verificando a topologia NUMA no Linux
lscpu | grep NUMA
Exemplo de Saída:
NUMA node(s): 2
NUMA node0 CPU(s): 0-23,48-71
NUMA node1 CPU(s): 24-47,72-95
Neste cenário, sabemos exatamente quais IDs de CPU pertencem a cada processador físico. Também sabemos que as CPUs de 48 a 95 são threads virtuais (Hyper-Threading), que geralmente evitamos para os VPs principais de CPU do banco de dados para garantir ciclos de clock dedicados.
Configurando a Afinidade no Informix (onconfig)
O IBM Informix (especialmente nas versões mais recentes, como a 14.10) possui um controle granular excelente sobre onde seus Virtual Processors vão rodar. Isso é feito através do parâmetro VPCLASS no arquivo onconfig.
Em vez de deixar o sistema operacional (Linux) jogar os processos do Informix de um lado para o outro (causando context switching e perda de cache L3), nós "amarramos" (pin) os VPs a CPUs específicas.
Exemplo Prático de Configuração:
Vamos alocar 24 VPs de CPU para o Informix, distribuindo a carga de forma inteligente e usando apenas núcleos físicos reais. Vamos definir a afinidade para usar as CPUs de 0 a 11 (Nó 0) e de 24 a 35 (Nó 1).
# Configuração no arquivo onconfig
# num=24 : Cria 24 Virtual Processors da classe CPU
# aff=(0-11,24-35) : Amarra os VPs aos núcleos físicos específicos
VPCLASS cpu,num=24,aff=(0-11,24-35)
Por que essa configuração é um divisor de águas?
- Isolamento de Cache L3: Como o VP do Informix nunca muda de CPU, os dados que ele processa permanecem quentes no cache L3 do processador, acelerando leituras subsequentes.
- Redução de Context Switching: O Linux não gasta recursos tentando balancear os processos do banco de dados entre os núcleos.
- Previsibilidade: Em ambientes de alta concorrência, você garante que o Informix sempre terá aqueles 24 núcleos físicos dedicados a ele, imunes a picos de processamento de outras aplicações (como agentes de backup ou monitoramento).
Conclusão
Afinidade de CPU não é "micro-otimização", é arquitetura básica para servidores de grande porte. Se você roda IBM Informix em máquinas com dezenas de núcleos e não configurou o parâmetro aff= no seu VPCLASS, seu banco de dados está deixando performance na mesa.
Sempre mapeie sua topologia com lscpu, isole os núcleos físicos dos lógicos (HT) e amarre seus VPs. O tempo de resposta das suas queries vai agradecer.
Nenhum comentário:
Postar um comentário