Ao solucionar problemas de desempenho da CPU em SQL Servers virtualizados em execução no VMware, uma das primeiras coisas que faço é verificar se a configuração da máquina virtual não é um fator que contribui para o problema de desempenho. Onde um servidor físico tem 100% dos recursos disponíveis dedicados ao sistema operacional, uma máquina virtual não tem, portanto, analisar alguns itens básicos antecipadamente elimina a solução de problemas errados e a perda de tempo. No passado, escrevi no blog sobre a importância dos DBAs terem acesso somente leitura ao Virtual Center for VMware para solução básica de problemas de desempenho. No entanto, mesmo sem acesso ao Virtual Center, ainda é possível descobrir algumas informações básicas dentro do Windows que podem levar a possíveis problemas no nível do host que estão afetando o desempenho.
Cada máquina virtual VMware tem dois grupos de contadores de desempenho no Windows que são adicionados quando as ferramentas VMware são instaladas no convidado; Processador VM e Memória VM. Esses contadores de desempenho são uma das primeiras coisas que observo sempre que estou trabalhando com uma máquina virtual no VMware, pois fornecem uma visão de quais recursos a VM está recebendo do hipervisor. O grupo de processadores de VM tem os seguintes contadores:
- % de tempo do processador
- Velocidade efetiva da VM em MHz
- Velocidade do processador host em MHz
- Limite em MHz
- Reserva em MHz
- Compartilhamentos
Em uma VM convidada que está mostrando um alto Processador\% Tempo do Processador no Gerenciador de Tarefas ou perfmon, a verificação dos contadores de Processador da VM fornecerá uma conta precisa das alocações de recursos reais que a VM convidada está recebendo. Se a velocidade do processador host em MHz for 3000 e o convidado tiver 8 CPUs virtuais alocadas a ele, a velocidade efetiva máxima para a VM será 24000 MHz e o contador de velocidade efetiva da VM em MHz refletirá se a VM está realmente obtendo os recursos de O hospedeiro. Normalmente, quando esse for o caso, você precisará começar a examinar as informações no nível do host para diagnosticar melhor a causa raiz do problema. Mas em um compromisso recente com o cliente, esse não foi o caso.
A VM do cliente neste caso correspondia à configuração descrita acima e tinha uma velocidade efetiva máxima de 24.000 MHz, mas o contador de Velocidade Efetiva da VM em MHz estava em média apenas em torno de 6.900 MHz com o tempo do Processador Percentual do Windows da VM atrelado a quase 100%. Observar logo abaixo do contador Velocidade efetiva da VM em MHz revelou a causa do problema:o Limite em MHz era 7.000, o que significa que a VM tinha um limite configurado de uso da CPU em 7.000 MHz no ESX, portanto, estava sendo constantemente limitado pelo hipervisor em carregar.
A explicação para isso foi que essa VM em particular foi usada para fins de teste em uma prova de conceito e foi originalmente co-localizada em um host de VM ocupado; os administradores de VM não queriam uma carga de trabalho desconhecida causando problemas de desempenho nesse host. Portanto, para garantir que não impactasse negativamente as cargas de trabalho de produção reais no host durante o POC, foi limitado a permitir apenas 7.000 MHz de CPU ou o equivalente a 2 1/3 núcleos físicos no host. Por fim, a remoção do limite de CPU da VM no ESX eliminou os problemas de alta CPU no Windows e os problemas de desempenho que o cliente estava enfrentando desapareceram.
O grupo de contadores de memória de VM é tão importante quanto o grupo de processadores de VM para identificar possíveis problemas de desempenho para o SQL Server. O grupo de contadores de memória VM contém os seguintes contadores:
- Memória ativa em MB
- Memória sobrecarregada em MB
- Limite de memória em MB
- Memória mapeada em MB
- Sobrecarga de memória em MB
- Reserva de memória em MB
- Memória compartilhada em MB
- Memória compartilhada salva em MB
- Compartilhamentos de memória
- Memória trocada em MB
- Memória usada em MB
Desses contadores, os que analiso especificamente são a Memória Ballooned em MB e a Memória Swapped em MB, ambas as quais devem ser zero para cargas de trabalho do SQL Server. O contador Memory Ballooned in MB informa quanta memória foi recuperada da VM convidada pelo driver de balão devido à superalocação de memória no host, o que fará com que o SQL Server reduza o uso de memória para responder à pressão de memória no Windows causada pelo driver de balão inflando para tirar a memória da VM. O contador Memória trocada em MB está rastreando quanta memória foi paginada para o disco pelo hipervisor do host devido à superalocação de memória no host que não pôde ser resolvida com o balão de convidados da VM com o driver de balão. O guia de práticas recomendadas da VMware para SQL Server recomenda o uso de reservas para garantir que o SQL Server não seja expandido ou paginado por motivos de desempenho, mas muitos administradores de VM hesitam em definir reservas estáticas porque isso reduz a flexibilidade do ambiente.
Ferramentas de monitoramento, como o SentryOne V Sentry, também podem ajudar. Considere o caso em que você pode não ter acesso direto ao vCenter, mas alguém pode configurar o monitoramento em seu nome. Agora você pode obter uma ótima visualização e insights sobre problemas de CPU, memória e até mesmo de disco – tanto no nível do convidado quanto do host – e todo o histórico que vem com isso também. No painel abaixo, você pode ver as métricas de host à esquerda (incluindo detalhamentos de CPU para co-stop e tempo de prontidão) e métricas de convidado à direita:
Para experimentar esta e outras funcionalidades do SentryOne, você pode baixar uma avaliação gratuita.
Conclusão
Ao solucionar problemas de desempenho em SQL Servers virtualizados no VMware, é importante analisar o problema de um ponto de vista holístico, em vez de fazer uma solução de problemas “instintiva” usando apenas informações limitadas. Os contadores específicos do VMware no Monitor de desempenho podem ser uma ótima maneira de verificar rapidamente se a VM está obtendo as alocações básicas de recursos do host, antes de executar outras etapas para solucionar o problema.
