o problema
Um servidor de datacenter moderno tem mais de um socket. Cada socket carrega o próprio controlador de memória e os próprios bancos de DRAM. Quando um core precisa de um endereço que mora do outro lado, o acesso atravessa o interconnect entre sockets: mais latência, menos banda. É isso que a sigla NUMA descreve, non-uniform memory access. O modelo mental que todo mundo usa para raciocinar sobre performance — memória é memória, o que importa é se está em cache ou não — para de valer nessa máquina.
Numa máquina só, isso é um detalhe que um profiler resolve. Numa frota, muda de natureza. São milhares de servidores, cada um rodando vários jobs ao mesmo tempo, colocados ali por um escalonador que otimiza empacotamento, não topologia de memória. O programador da aplicação não escolhe socket e normalmente não sabe qual recebeu. O resultado de uma colocação ruim é uma perda difusa: não aparece em benchmark de máquina única, não quebra nada, e some no ruído de latência de produção — até ser multiplicada pelo tamanho da frota, quando vira dinheiro.
a ideia
O título é o argumento: NUMA tratado como assunto de warehouse-scale computer, não de servidor. A palavra “experience” marca o gênero — relato do que aparece quando a máquina está sob carga real de produção, com vizinhos disputando os mesmos recursos, e não sob um microbenchmark rodando sozinho. É a diferença entre medir o custo de um acesso remoto e medir o que acontece com um serviço de busca quando o escalonador espalhou as threads dele por dois sockets.
Aqui vale uma ressalva de honestidade: o resumo deste paper não estava no material recebido, só o título, os seis autores e o venue, o HPCA de 2013. Nada do que segue descreve o experimento, a metodologia ou os resultados dos autores, porque nenhum deles foi lido. O que está neste verbete se apoia no que o título sustenta e no que é conhecimento público sobre NUMA e computação em escala de datacenter.
o que isso custou
O trade-off central de qualquer política NUMA-aware não tem saída limpa. Concentrar um job num socket melhora locality e piora a disputa por cache de último nível e por banda local de memória. Espalhar o job alivia o hotspot e paga em acessos remotos. A política certa depende do perfil do job, e num datacenter os jobs são heterogêneos por construção.
Tem um custo maior, e é organizacional. Toda restrição de colocação que o escalonador aceita reduz a liberdade dele de empacotar. Menos liberdade é menos utilização, e utilização é a métrica que justifica o investimento no datacenter inteiro. Otimizar NUMA é gastar uma moeda cara para comprar outra: só compensa quando o ganho medido em produção supera o que se perdeu de densidade. Quais limites os próprios autores declaram, não dá para dizer sem o texto.
onde isso aparece hoje
O ferramental virou rotina: numactl, cpusets, cgroups, políticas de alocação de página no Linux e APIs de afinidade nos runtimes. Quem escreve serviço em Rust ou Go e mede latência de cauda alta sem explicação acaba nesse território mais cedo ou mais tarde.
A linhagem é visível na literatura do próprio Google. A ideia de tratar o datacenter como uma máquina só vem de Web Search for a Planet: The Google Cluster Architecture. O escalonador que decide onde cada tarefa roda é descrito em Large-scale cluster management at Google with Borg. E a razão de interferência entre vizinhos importar tanto está em The Tail at Scale: num serviço que espera a resposta mais lenta entre centenas, a variabilidade causada por colocação é o que define a latência que o usuário vê.