Quando o ESX 5 e o Hyper-V no Windows Server 2012 foram lançados e alterados as limitações que existiam anteriormente para tamanhos de VM, eu soube quase imediatamente que veríamos mais cargas de trabalho de SQL Server de grande escala começarem a ser virtualizadas. Trabalhei com vários clientes no ano passado que estavam virtualizando de 16 a 32 SQL Servers principais por vários motivos, desde estratégias simplificadas de recuperação de desastres que correspondiam ao resto dos negócios até consolidação e custo total de propriedade mais baixo em hardware mais recente plataformas. Um dos motivos para a mudança de escalabilidade com o ESX 5+ foi a introdução do NUMA virtual (vNUMA) para convidados amplos que excediam o tamanho de um nó NUMA de hardware individual. Com o vNUMA, a VM convidada é otimizada para corresponder à topologia NUMA de hardware, permitindo que o sistema operacional convidado e quaisquer aplicativos com reconhecimento de NUMA, como SQL Server, que estejam sendo executados na VM, aproveitem as otimizações de desempenho do NUMA, como se fossem rodando em um servidor físico.
No VMware, uma topologia vNUMA está disponível na versão de hardware 8 ou superior e é configurada por padrão se o número de vCPUs for maior que oito para o convidado. Também é possível configurar manualmente a topologia vNUMA para uma VM usando opções de configuração avançadas, o que pode ser útil para VMs que têm mais memória alocada a elas do que um nó NUMA físico pode fornecer, mas ainda usa oito ou menos vCPUs. Na maioria das vezes, as configurações padrão funcionam para a maioria das VMs que examinei nos últimos anos, mas há certos cenários em que a topologia vNUMA padrão não é ideal e a configuração manual pode fornecer alguns benefícios. Recentemente eu estava trabalhando com um cliente com um número de 32 vCPUs SQL Server VMs com 512 GB de RAM alocados fazendo alguns ajustes de desempenho onde a topologia vNUMA não era nada perto do que era esperado.
Os servidores host de VM nesse ambiente eram quatro processadores soquete E5-4650 de oito núcleos e 1 TB de RAM, cada um dedicado a uma única VM do SQL Server em operações típicas, mas com capacidade disponível para sustentar duas VMs em um cenário de falha. Com esse layout de hardware, há quatro nós NUMA, um por soquete, e a configuração de VM esperada também teria 4 nós vNUMA apresentados para uma configuração de 32 vCPU. No entanto, o que encontrei ao examinar os DMVs no SQL Server foi que esse não era o caso:
Figura 1 – Configuração vNUMA incorreta
Como você provavelmente pode ver na imagem, algo está realmente errado com a configuração do NUMA neste servidor. Existem quatro nós de memória no SQLOS e apenas um único nó de CPU, com todas as vCPUs alocadas nele. Para ser perfeitamente honesto, isso me surpreendeu quando vi porque ia contra tudo o que eu sabia sobre como o SQLOS configurava as estruturas internas na inicialização da instância. Depois de pesquisar um pouco nos arquivos ErrorLog, Performance Monitor e Windows Task Manager, baixei uma cópia do CoreInfo do SysInternals e dei uma olhada no layout NUMA sendo relatado ao Windows.
Processador lógico para mapa de soquete:
********———————— Soquete 0
——–********—————- Soquete 1
—————-********——– Soquete 2
————————******** Soquete 3
Processador Lógico para Mapa de Nó NUMA:
******************************** Nó NUMA 0
A saída do CoreInfo confirmou que a VM apresenta as 32 vCPUs como 4 soquetes diferentes, mas agrupou todas as 32 vCPUs no NUMA Node 0. Observando os contadores de desempenho do Windows Server 2012 na VM, pude ver no grupo de contadores de memória do NUMA Node, que 4 nós de memória NUMA foram apresentados ao sistema operacional com a memória distribuída uniformemente pelos nós. Isso tudo estava alinhado com o que eu estava vendo no SQLOS, e também pude dizer pelas entradas ERRORLOG de inicialização que a máscara de CPU para o nó estava mascarando todas as CPUs disponíveis no Nó de CPU 0, mas quatro alocadores de página grandes estavam sendo criados, um para cada nó de memória.
22/09/2013 05:03:37,Server,Unknown,Node configuration:node 0:CPU mask:0x00000000ffffffff:0 Active CPU mask:0x00000000ffffffff:0. Esta mensagem fornece uma descrição da configuração do NUMA para este computador. Esta é apenas uma mensagem informativa. Nenhuma ação do usuário é necessária.
22/09/2013 05:03:37,Servidor,Desconhecido,Esta instância do SQL Server foi relatada pela última vez usando um ID de processo de 1596 em 22/09/2013 05:00:25 (local) 22/09/2013 10:00:25 (UTC). Esta é apenas uma mensagem informativa; nenhuma ação do usuário é necessária.
22/09/2013 05:03:35,Servidor,Desconhecido,Página grande alocada:32 MB
22/09/2013 05:03:35,Servidor,Desconhecido,Grande Página alocada:32 MB
22/09/2013 05:03:35,Servidor,Desconhecido,Página grande alocada:32 MB
22/09/2013 05:03:35,Servidor,Desconhecido,Página grande alocada :32 MB
22/09/2013 05:03:35,Servidor,Desconhecido,Usando páginas bloqueadas no gerenciador de memória.
22/09/2013 05:03:35,Servidor,Desconhecido,Detectado 524287 MB de RAM. Esta é uma mensagem informativa; nenhuma ação do usuário é necessária.
22/09/2013 05:03:35,Servidor,Desconhecido,SQL Server está iniciando na base de prioridade normal (=7). Esta é apenas uma mensagem informativa. Nenhuma ação do usuário é necessária.
22/09/2013 05:03:35,Servidor,Desconhecido,SQL Server detectou 4 soquetes com 8 núcleos por soquete e 8 processadores lógicos por soquete 32 processadores lógicos no total; usando 32 processadores lógicos baseados no licenciamento do SQL Server. Esta é uma mensagem informativa; Não é necessária nenhuma ação do usuário.
Nesse ponto, eu tinha certeza de que era algo relacionado à configuração da VM, mas não consegui identificar qual era especificamente o problema, pois nunca tinha visto esse comportamento em outras VMs SQL Server amplas que ajudei clientes no VMware ESX 5+ no passado. Depois de fazer algumas alterações de configuração em um servidor de VM de teste que estava disponível, apenas nenhuma delas corrigiu a configuração vNUMA apresentada dentro da VM. Depois de entrar em contato com o suporte da VMware, fomos solicitados a desativar o recurso vCPU hotplug para a VM de teste e ver se isso corrigia o problema. Com o hotplug desabilitado na VM, a saída CoreInfo confirmou que o mapeamento vNUMA dos processadores para a VM agora estava correto:
Processador lógico para mapa de soquete:
********———————— Soquete 0
——–********—————- Soquete 1
—————-********——– Soquete 2
————————******** Soquete 3
Processador Lógico para Mapa de Nó NUMA:
********———————— Nó NUMA 0
——–********————— - Nó NUMA 1
—————-********——– Nó NUMA 2
————————******** Nó NUMA 3
Esse comportamento está documentado no artigo VMware KB (vNUMA é desabilitado se o hotplug VCPU estiver habilitado), de outubro de 2013. Essa foi a primeira VM ampla para SQL Server com a qual trabalhei onde o hotplug vCPU foi habilitado, e é não é uma configuração típica que eu esperaria para uma VM de 32 vCPU, mas fazia parte do modelo padrão usado no cliente e afetou o SQL Server.
Efeitos da desativação do vNUMA
Há vários efeitos que a desabilitação do vNUMA dessa forma pode ter em uma carga de trabalho, mas há dois problemas específicos que podem afetar o SQL Server especificamente nesse tipo de configuração. A primeira é que o servidor pode ter problemas com acumulações de espera CMEMTHREAD, pois há 32 vCPUs alocadas para um único nó NUMA e o particionamento padrão para objetos de memória no SQLOS é por nó NUMA. Esse problema específico foi documentado por Bob Dorr no grupo CSS da Microsoft em sua postagem no blog SQL Server 2008/2008 R2 em máquinas mais novas com mais de 8 CPUs apresentadas por nó NUMA pode precisar do sinalizador de rastreamento 8048. Como parte da revisão das estatísticas de espera na VM com o cliente, observei que CMEMTHREAD era o segundo tipo de espera mais alto, o que é anormal pela minha experiência e me fez observar a configuração do SQLOS NUMA mostrada na Figura 1 acima. Nesse caso, o sinalizador de rastreamento não é a solução, remover o hotplug de vCPU da configuração da VM resolve o problema.
O segundo problema que afetaria o SQL Server especificamente se você estiver em uma versão sem patch está associado ao gerenciamento de memória NUMA no SQLOS e à maneira como o SQLOS rastreia e gerencia as páginas Away durante a fase inicial de aumento de memória após a inicialização da instância. Esse comportamento foi documentado por Bob Dorr na postagem do blog CSS, How It Works:SQL Server (NUMA Local, Foreign and Away Memory Blocks). Essencialmente, quando o SQLOS tenta uma alocação de memória de nó local durante a aceleração inicial, se o endereço de memória retornado for de um nó de memória diferente, a página é adicionada à lista Away e outra tentativa de alocação de memória local ocorre e o processo se repete até uma alocação de memória local é bem-sucedida ou o destino de memória do servidor é atingido. Como três quartos da memória de nossas instâncias existem em nós NUMA sem nenhum agendador, isso cria uma condição de desempenho degradada durante o aumento inicial da memória para a instância. Atualizações recentes mudaram o comportamento da alocação de memória durante a aceleração inicial para tentar apenas a alocação de memória local um número fixo de vezes (o número específico não está documentado) antes de usar a memória externa para continuar o processamento. Essas atualizações estão documentadas no KB nº 2819662, CORREÇÃO:problemas de desempenho do SQL Server em ambientes NUMA.
Resumo
Para VMs amplas, definidas como tendo mais de 8 vCPUs, é desejável que o vNUMA seja passado para a VM pelo hipervisor para permitir que o Windows e o SQL Server aproveitem as otimizações de NUMA em sua base de código. Como resultado, essas VMs mais amplas não devem ter a configuração de hotplug vCPU habilitada, pois isso é incompatível com vNUMA e pode resultar em desempenho degradado para o SQL Server quando virtualizado.
