Neste post, discutirei uma metodologia geral para solucionar problemas de desempenho da CPU. Gosto de aplicar metodologias por padrão e também gosto de construir eficiências na forma como soluciono problemas com base em experiências anteriores. Sem uma estrutura geral, torna-se muito fácil perder a verdadeira causa raiz no meio de uma crise.
As etapas que descreverei neste post são as seguintes:
- Defina o problema
- Validar as condições atuais
- Responder “É o SQL Server”?
- Identificar consumidores de CPU
- Corresponder ao padrão e resolver
Este artigo abordará cada uma dessas etapas. Estarei assumindo que você pode não estar usando uma ferramenta de monitoramento de terceiros. Se estiver, a estrutura aqui ainda se aplica, mas suas fontes de dados e ferramentas à sua disposição variam do que descrevo.
Defina o problema
Primeiro, precisamos de escopo a questão. Quando alguém chega até você e diz que está vendo um problema de desempenho da CPU, isso pode significar várias coisas diferentes. Portanto, a primeira tarefa é entender qual é a natureza do problema de desempenho da CPU atualmente.
Algumas categorias comuns incluem:
- A disponibilidade está sendo afetada devido a "CPUs rastreados". Por exemplo, todos os agendadores funcionando a 100% em todos os níveis e a taxa de transferência sendo interrompida ou significativamente reduzida.
- Degradação do desempenho devido ao uso da CPU “superior ao normal”. Portanto, não estamos vinculados, mas suas CPUs estão sendo executadas em uma porcentagem maior do que o normal e, presumivelmente, isso está afetando o desempenho.
- Outra categoria comum de problema de desempenho da CPU é o cenário de "vencedores e perdedores", em que as cargas de trabalho competem entre si. Talvez você tenha uma carga de trabalho OLTP que esteja encontrando uma taxa de transferência reduzida devido a uma consulta de relatório em execução paralela.
- Outro problema pode ser o encontro de um ponto de inflexão – onde a capacidade geral e as limitações de escalabilidade do seu sistema são atingidas em um determinado ponto.
Menciono essas categorias abrangentes como ponto de partida, mas sei que muitas vezes pode haver fortes dependências entre esses problemas e uma categorização pode se misturar à outra. Com isso dito, o primeiro passo é definir os sintomas e problemas da forma mais clara possível.
Validar as condições atuais
Se o problema aconteceu no passado ou está acontecendo agora, é importante obter o máximo possível de informações básicas sobre o sistema, a carga de trabalho e as configurações. Se você estiver usando linhas de base e run-books, o ideal é que você já esteja rastreando muitas dessas informações. Se não, pergunte a si mesmo com que rapidez você pode obter respostas a essas perguntas às 2 da manhã no meio de uma crise.
As subseções a seguir cobrem pontos de dados importantes que normalmente me interessam para um problema de desempenho da CPU.
- Quantos soquetes e núcleos?
- O hyper-threading está ativado?
- Qual é o modelo do processador, arquitetura (32 bits/64 bits)?
- Este é um convidado virtual?
- Se sim, agora você também vai se interessar por detalhes sobre o anfitrião e os outros convidados virtuais com os quais você está compartilhando recursos.
- Há alguma configuração relacionada à CPU em vigor?
- Por exemplo, CPU Hyper-V
- Quantas vCPUs são alocadas entre os convidados?
- Quantas vCPUs este convidado tem?
- O convidado foi migrado recentemente para um novo host antes do problema?
- Grau máximo de configuração de paralelismo
- Limite de custo para a opção de paralelismo
- Configuração de afinidade do processador
- Configuração de aumento de prioridade
- Configuração máxima de threads de trabalho
- Configuração de pool leve
- Qual é a configuração da opção de energia? (nível do SO, host da VM ou controlado pelo BIOS)
- Alto desempenho, equilíbrio e economia de energia?
- Ele está configurado além das configurações padrão?
- Você vê algum aviso ou erro incomum?
Detalhes do servidor físico
Detalhes do servidor virtual
Reserva, Reserva de CPU VMware, Peso Relativo da CPU Hyper-V e Compartilhamentos de CPU VMware.
Definições de configuração da instância do SQL Server
As três primeiras configurações podem exigir uma discussão mais aprofundada. Raramente há absolutos em relação a essas configurações.
Em relação às três últimas configurações, como “aumento de prioridade”, se eu ver que eles estão em valores não padrão, definitivamente vou pressionar por mais informações e histórico.
Configurações de opções de energia da CPU
As configurações de opções de energia abaixo de “Alto Desempenho” ainda são muito comuns e não devem ser ignoradas para servidores que hospedam instâncias do SQL Server.
Configuração do administrador de recursos
Ainda acho raro encontrar clientes usando esse recurso, mas é fácil validar se ele está sendo usado e valerá a pena pelas vezes em que estiver realmente configurado além do padrão.
Log de erros do SQL Server e logs de eventos do Windows
Por que procurar nos logs de erros e eventos um problema de CPU? Às vezes, problemas upstream podem causar problemas de desempenho downstream no SQL Server. Você não quer perder tempo ajustando uma consulta ou adicionando um novo índice quando o problema de causa raiz do upstream é um problema de degradação do componente de hardware.
Resposta "É o SQL Server?"
Parece óbvio quando pergunto, mas você realmente não quer gastar uma quantidade significativa de tempo solucionando um problema de CPU alta no SQL Server se o culpado não for realmente o SQL Server.
Em vez disso, reserve um momento para verificar qual processo está consumindo mais CPU. Existem várias opções para escolher, incluindo:
- Processo:% de tempo do usuário (modo de usuário)
- Processo:% de tempo privilegiado (modo kernel)
- Gerenciador de Tarefas
- Explorador de processos
- Informações recentes da CPU via sys.dm_os_ring_buffers ou a sessão de integridade do sistema para as instâncias específicas do SQL Server em execução no sistema
Se for o SQL Server e você tiver várias instâncias do SQL Server para escolher, verifique se está solucionando o problema da instância correta do SQL Server no host. Existem algumas maneiras de fazer isso, incluindo o uso de
SELECT SERVERPROPERTY('processid') para obter o PID e, em seguida, associá-lo ao Gerenciador de Tarefas ou ao Process Explorer.Depois de confirmar que é o SQL Server, você está vendo tempo de usuário alto ou tempo privilegiado (kernel)? Novamente, isso pode ser confirmado via Process:% Privileged Time (objeto sqlservr) e também pelo Windows Task Manager ou Process Explorer.
Embora os problemas de tempo de kernel alto devam ser raros, eles ainda exigem caminhos de solução de problemas diferentes dos problemas de solução de problemas de CPU de tempo de usuário padrão. Algumas causas potenciais de tempo de kernel alto incluem drivers de filtro defeituosos (antivírus, serviços de criptografia), atualizações e drivers de firmware desatualizados ou ausentes ou componentes de E/S defeituosos.
Identificar consumidores de CPU
Depois de validar qual instância do SQL Server está direcionando o uso da CPU de tempo do usuário no sistema, há muitos exemplos de consulta pré-enlatados na Web que você pode usar.
Abaixo está uma lista de DMVs que as pessoas geralmente usam de várias formas durante um problema de desempenho. Eu estruturei isso em um formato de perguntas e respostas para ajudar a enquadrar por que você deseja acessá-los.
- sys.dm_exec_requests
- sys.dm_exec_sql_text
- sys.dm_exec_sessions
- sys.dm_exec_connections
- sys.dm_exec_query_plan
- sys.dm_os_waiting_tasks
- sys.dm_exec_query_stats
- Agregar por total_worker_time
- Definir médias com execution_count
- Se forem cargas de trabalho ad hoc, você poderá agrupar por query_hash
- Use plan_handle com sys.dm_exec_query_plan para obter o plano
- sys.dm_os_tasks
- Ordenado por session_id, request_id
- sys.dm_exec_query_plan
- Veja os operadores do plano, mas lembre-se de que este é apenas o plano estimado
- sys.dm_exec_query_stats
- Filtrar total_elapsed_time menor que total_worker_time
- Mas observe que isso pode ser um falso negativo para cenários de bloqueio, em que a duração é inflada devido a uma espera no recurso
Quais solicitações estão sendo executadas no momento e qual é o status delas?
O que ele está executando?
De onde é?
Qual é o seu plano estimado? (mas tome cuidado ao destruir xml em um sistema já com restrição de CPU)
Quem está esperando por um recurso e o que eles estão esperando?
Quais consultas consumiram mais tempo de CPU desde a última reinicialização?
Esta consulta está usando paralelismo?
Combine o padrão e resolva
Você provavelmente está rindo dessa etapa em particular – pois esta pode ser a mais envolvida (e é outra razão pela qual os profissionais do SQL Server são empregados com remuneração). Existem vários padrões diferentes e resoluções associadas - então, terminarei este post com uma lista dos drivers de problemas de desempenho da CPU mais comuns que vi nos últimos anos:
- Operações de E/S altas (e, na minha experiência, esse é o driver mais comum da CPU)
- Problemas de estimativa de cardinalidade (e baixa qualidade do plano de consulta associado)
- Paralelismo inesperado
- Compilação / recompilação excessiva
- Chamadas UDF de cálculo intensivo, operações de fragmentação
- Operações de linha agonizantes
- Atividades de manutenção simultâneas (por exemplo, ATUALIZAR estatísticas com FULLSCAN)
Cada área que identifiquei tem um grande corpo de trabalho associado para pesquisar. Em termos de recursos consolidados, ainda acho que um dos melhores ainda é o artigo técnico “Troubleshooting Performance Problems in SQL Server 2008” escrito por Sunil Agarwal, Boris Baryshnikov, Keith Elmore, Juergen Thomas, Kun Cheng e Burzin Patel.
Resumo
Como acontece com qualquer metodologia, existem limites para sua utilização e áreas em que se justifica improvisar. Observe que não estou sugerindo que as etapas que descrevi neste post sejam usadas como uma estrutura rígida, mas considero um ponto de partida para seus esforços de solução de problemas. Mesmo profissionais altamente experientes do SQL Server podem cometer erros de principiante ou ser influenciados por suas experiências de solução de problemas mais recentes, portanto, ter uma metodologia mínima pode ajudar a evitar a solução de problemas errados.
