Afinidade no dia a dia técnico
Quando alguém pergunta o que significa afinidade, a resposta mais útil depende do contexto, mas na prática de infraestrutura e desenvolvimento, quase sempre se fala em afinidade de CPU — aquela capacidade de um processo ou thread de ficar preso a um núcleo específico do processador. Não é mágica, é apenas uma flag no escalonador do sistema operacional que limita onde determinada tarefa pode rodar.
Como a afinidade funciona na realidade
O Linux expõe isso via taskset ou via API sched_setaffinity(). Você passa uma máscara de bits, e o kernel garante que aquele processo só execute nos núcleos selecionados. O exemplo mais comum: taskset -c 0-3 ./meu_servidor
Isso prenderia o processo aos núcleos 0, 1, 2 e 3. Simples. Mas o que as pessoas não entendem é que isso tem custo. Deslocamento de cache cai quando você trava um processo em poucos núcleos, porque o conteúdo do cache L1/L2 não migra entre os cores conforme o processo seria movido pelo escalonador normal. Em alguns casos isso melhora latência. Em outros, piora throughput. Tudo depende do workload. Já vi gente prender serviços inteiros de banco de dados em núcleos isolados achando que estava resolvendo latência. O problema real era outro — config de NUMA desbalanceada. A afinidade só mascarou o sintoma por duas semanas até o problema voltar com coisa pior.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Quando usar e quando não usar
Afinidade faz sentido quando você tem um serviço de baixa latência que não tolera migration de thread entre núcleos. Servidores de trading, processos de áudio profissional, alguns workloads de rede com DPDK. Nestes casos, isolar o núcleo e fixar a thread economia uns 5 a 15 microssegundos de jitter por operação, dependendo do hardware. Não faz sentido para aplicações web comuns, scripts Python, ou qualquer coisa que rode em container com orquestração dinâmica. Kubernetes já faz seu próprio tipo de afinidade com node selectors e taints/tolerations, mas isso é afinidade de node, não de CPU. Confundir os dois é erro frequente. Minha recomendação: use cpuset cgroup dentro do container se precisar de controle fino, não taskset direto no host.
Um problema real que encontrei
Numa migração de VMs com SR-IOV, um serviço de packet processing tinha afinidade configurada manualmente via script legado. Após uma atualização de kernel, a numeração dos núcleos físicos mudou porque a hierarquia PCI reorganizou. O processo continuou rodando, mas nos núcleos errados. O throughput despencou de 8 Gbps para 1.2 Gbps. Ninguém percebeu porque os logs de aplicação não mostravam erro. A solução foi refatorar o script para usar nomes topológicos dos núcleos em vez de números brutos, e adicionar um healthcheck que compara latência medida contra baseline antes de considerar a affinidade como correta.
Limitações que ninguém menciona
Afinidade de CPU não é persistente entre reinicializações por padrão. Se o serviço restartar, a máscara some. Você precisa de unit file no systemd, entry em crontab, ou configuração de container. Também não funciona bem com hyperthreading ativo — os pares de threads compartilhados são apenas dois lógica cores em um core físico, e fixar um thread em cada membro do par pode criar contentão no cache e na unidade de execução, não ganho algum. Se o seu workload é multi-threaded com muitas variáveis de estado espalhadas, a afinidade pode aumentar a contenção de lock entre threads que agora compartilham o mesmo cache coeso. O efeito colateral é ops mais lentas, não mais rápidas. Teste sempre com o workload real, nunca com microbenchmark isolado.
Resumo prático
Afinidade é ferramenta, não solução. Ela existe para dar controle determinístico sobre onde código executa. O uso típico é reduzir jitter em workloads sensíveis a migração de thread. O erro típico é aplicá-la em tudo que tem latência alta e esperar milagre. Se o problema é I/O wait, afinidade de CPU não resolve. Se é contenção de lock, pode piorar. Sempre valide com profiling antes de travar núcleos.
