Eu tive uma ligação interessante com um cliente hoje. Temos um aplicativo que agenda outros aplicativos e normalmente não temos nenhum problema com servidores com configuração NUMA com de 2 a 4 nós.
Na chamada, iniciamos dois aplicativos muito famintos por CPU e ambos foram alocados para o Nó 0 e, portanto, em toda a máquina, havia apenas 50% de uso. Depois que alteramos a segunda instância do aplicativo para o outro nó, estávamos usando todos os núcleos (metade em um aplicativo e metade no outro). Parecia impossível alocar um aplicativo para todos os núcleos.
Agora, a única diferença entre essa máquina e as que estou acostumado a usar é que o gerenciador de tarefas do Windows listou os nós em uma lista suspensa em vez de uma longa lista de núcleos individuais, portanto a Microsoft sabe qual é essa restrição , mas é um problema difícil pesquisar on-line.
Está bem claro que teremos que desenvolver afinidades no NUMA, mas por enquanto estou tentando entender o problema. O que pode fazer com que um estilo de máquina NUMA permita que os aplicativos usem ambos os nós de forma transparente e o que está causando esse comportamento agora?
Eu posso ver essa arquitetura funcionando muito bem para muitos aplicativos pequenos, mas geralmente executamos monolíticos com muitos threads.
O servidor com o qual estou lutando é um HP Proliant DL388Gen9 com dois processadores Intel Xeon E5-2690V3.
Pensamentos sobre o que está causando isso?
Um processo só pode ser atribuído a um único nó NUMA. Essa é a resposta curta. Você não pode forçar uma única instância a ser executada em mais de um nó NUMA. E isso faz sentido, dado o propósito da NUMA, e também o propósito secundário de permitir que os núcleos da CPU em um sistema operacional que use máscara de bits de afinidade com a CPU de 64 bits.
Eu não sou especialista neste assunto, mas vou concordar com a minha opinião.
It's pretty clear we're going to have to develop NUMA node affinity, but for now I'm trying to understand the problem. What can cause one style of NUMA machine to allow applications to use both nodes transparently, and what's causing this behaviour now?
Eu sei que o Windows calcula uma "Distância do Nó", estimando a quantidade de tempo que leva para vários nós NUMA se comunicarem entre si. Não sei se sua latência ou largura de banda se baseia (ou talvez ambos), mas é importante saber.
Máquinas modernas, como o Skylake-Server, podem ter "SubNuma Clustering", onde diferentes partes do mesmo chip são reportadas como diferentes nós NUMA. No entanto, a diferença entre os nós dentro do mesmo chip é ~ 10 nanossegundos. Enquanto um soquete diferente pode ter ~ 200 nanossegundos.
Ex: Dois Xeon Golds (20 núcleos por CPU) com clustering sub-NUMA seriam parecidos com os nós 4x NUMA no Windows. Nós 2-NUMA por chip, representando os 10 núcleos "esquerdos" e os 10 núcleos "certos" em cada metade do chip. 3x controladores de memória à esquerda, 3x controladores de memória à direita. Mas todos os 20 núcleos podem falar com o controlador de memória em aproximadamente 80 nanossegundos. Eles podem apenas falar com o controlador de memória "mais próximo" em 70 nanossegundos. Uma diferença quase imperceptível, portanto, o Windows provavelmente prefere flutuar os threads nesses dois nós NUMA.
Minha suposição é que, sob as configurações padrão da sua configuração, o Windows decidiu que uma "Distância do Nó" era curta o suficiente para flutuar os encadeamentos, enquanto a outra configurava as distâncias da memória o suficiente para que as configurações padrão do Windows prefere manter os threads dentro de um nó NUMA.
Essa não é minha única teoria. Minha segunda teoria é que algo estranho está acontecendo com "Grupos de Processadores". Grupos de processadores são uma invasão de compatibilidade da API Win32, porque as máscaras de afinidade de CPU foram limitadas a 64 bits por motivos de desempenho. Portanto, os núcleos lógicos de 64 são o padrão máximo do Windows.
Você pode acessar mais de 64 núcleos lógicos por meio da API do grupo de processadores. link
Resumindo: se seus processos estiverem em "Grupos de processadores" separados, você será um programador para alterar o programa para suportar grupos de processadores.
Eu não fiz muitos testes com esse material pessoalmente. Mas espero que isso seja uma informação útil para você.
Tags process task-manager xeon numa