Se os usuários do seu banco de dados estão reclamando que o desempenho do SQL Server está fraco ultimamente, é possível que você esteja enfrentando os efeitos de um ou mais gargalos do SQL Server. Esses gargalos ocorrem por vários motivos, mas geralmente ocorrem como resultado de problemas com memória, E/S ou CPU.
Embora nem sempre seja fácil determinar se os problemas de desempenho se originam de um gargalo do SQL Server ou de outra fonte, você pode procurar esses sintomas comuns de gargalos para ajudar a restringir sua pesquisa pela origem do problema.
Sintomas comuns de gargalos do SQL Server
- SQL Server sobrecarregando o processador
- Tempos de execução mais longos nas consultas
- E/S excessiva
- Registro do aplicativo mostrando mensagens de falta de memória
- Atividade extrema nos discos
- Longos tempos de espera por E/S
O aparecimento repentino de um ou mais desses sintomas é uma boa indicação de que você tem um afunilamento do SQL Server em algum lugar do sistema. Agora, é seu trabalho encontrá-lo.
Tipos de gargalos do SQL Server
Existem três tipos principais de gargalos do SQL Server:memória, E/S e CPU. É importante que os DBAs estejam familiarizados com as causas, sintomas e correções de cada um para que possam identificar e remover os gargalos rapidamente e minimizar o impacto do baixo desempenho. Também incluímos alguns dos melhores contadores de desempenho para monitorar que ajudarão a identificar gargalos de desempenho imediatamente.
Afunilamentos de memória
Os gargalos de memória geralmente são resultado de recursos de memória insuficientes ou atividades do SQL Server consumindo a memória disponível. Os sintomas a serem observados incluem tempos de execução de consulta mais longos, E/S excessiva, mensagens de falta de memória no log do aplicativo e falhas frequentes do sistema.
As melhores maneiras de evitar gargalos relacionados à memória são usar um otimizador de consulta para eliminar consultas desnecessárias ou obsoletas e configurar a expectativa de vida da página em conjunto com a taxa de acertos do cache do buffer para limitar as viagens ao disco. Se for tarde demais para evitar o gargalo, tente revisar e ajustar consultas, reconfigurar a memória ou adicionar memória física.
Contadores para monitorar:memória disponível, memória total do servidor, memória do servidor de destino, páginas/s, taxa de acertos do cache do buffer
Afunilamentos de E/S
Quando não há armazenamento suficiente disponível para dar suporte a operações regulares de banco de dados, como TempDB, é provável que ocorram gargalos de E/S. Tempos de resposta longos, lentidão de aplicativos e tempos limite de tarefas frequentes são todos os principais indicadores de que você tem um gargalo de E/S.
Você pode evitar esse tipo de gargalo configurando o monitoramento com alarmes e alertas de limite para identificar quais atividades usam quantidades excessivas de armazenamento. Se ocorrer um gargalo de E/S, limite a leitura e a gravação das páginas do banco de dados de e para o disco. Isso exigirá que você verifique e corrija verificações de índice frequentes, consultas ineficientes e estatísticas desatualizadas.
Contadores a serem monitorados:comprimento médio da fila de disco, média de disco por segundo/leitura, média de disco por segundo/gravação, % de tempo de disco, média de leituras de disco/s, média de gravações de disco/s
Afunilamentos de CPU
A principal causa de gargalos de CPU são recursos de hardware insuficientes. É bastante fácil identificar esse gargalo verificando seus logs para determinar se o SQL Server está usando CPU excessiva.
Em um mundo ideal, você poderia evitar gargalos de CPU tendo um servidor dedicado somente para SQL Server e executando todos os outros softwares em outra máquina. Como essa não é uma opção para a maioria dos DBAs, você precisará saber como desobstruir sua CPU.
O primeiro passo é identificar os porcos da CPU. Depois de saber onde está o problema, você pode ajustar as consultas, melhorar seus planos de execução ou reconfigurar o sistema.
Contadores para monitorar:% de tempo do processador, solicitações em lote/s, compilações SQL/s, recompilações SQL/s
Uma história sobre gargalos de desempenho do SQL Server
“Temos alguns gargalos de desempenho do SQL Server para lidar”, disse meu chefe, em uma sexta-feira.
"Como você sabe?" Eu perguntei.
“As vendas estão reclamando que seu banco de dados está desacelerando ultimamente. Precisamos ver o que está acontecendo com isso.”
"OK. Vou reservar uma sala de conferências para que possamos sentar e trabalhar nisso.”
“Não se preocupe”, disse o chefe. “É tarde de uma sexta-feira. Isso significa que a melhor maneira de estudar os gargalos é com alguns dos nossos. Estamos indo para o Pike Pub no mercado.”
Entramos no bar escondido no Pike Place Market e encontramos uma pequena mesa perto da janela.
“Qual é o seu tipo favorito de gargalo?” perguntou o chefe.
Eu disse que era parcial para um Naughty Nellie no gargalo de 22 onças.
“Boa escolha”, disse o chefe. "Você pede isso, e eu quero a Citrus Summer Ale."
Enquanto esperávamos que nossos gargalos chegassem, começamos a tratar dos gargalos de desempenho do SQL Server.
“Precisaremos verificar se há problemas em vários lugares”, disse o chefe. “Eles podem ser problemas com memória, armazenamento ou processadores, mas todos parecem iguais para os usuários, certo? Desempenho mesquinho.
“Problemas de CPU não são tão difíceis de encontrar. Se esse for o problema, veremos que o SQL Server está sobrecarregando o processador e causando picos o tempo todo.
“Se for um problema de memória, veremos coisas como tempos de execução mais longos nas consultas e mais E/S porque o aplicativo precisa ficar sem disco. Também podemos verificar o log do aplicativo para mensagens de falta de memória.
“E se o gargalo estiver no armazenamento, veremos atividades extremas nos discos e longos tempos de espera por E/S.”
Nossos gargalos chegaram. Nós os estudamos cuidadosamente enquanto consideramos o problema de desempenho mais profundamente.
As muitas fontes potenciais de gargalos de desempenho do SQL Server
“E se for um problema de E/S?” Eu perguntei. “Devemos ver se o tempo de espera do WRITELOG é muito alto, comparado ao tempo total de espera. Ou, falando em I/O, talvez haja um problema no próprio SQL. Se houver um código ineficiente, como um NESTED LOOP JOIN em uma tabela enorme, o SQL pode estar pedindo para ler linhas na tabela interna zilhões de vezes. Isso realmente puniria o desempenho.”
“Pode ser”, disse o chefe. “Uniões complexas e operações de classificação podem ser difíceis, especialmente quando o banco de dados tempdb não está configurado corretamente. A contenção de Tempdb se parece com bloqueios de banco de dados comuns, mas na verdade é uma contenção travada por causa de processos simultâneos, todos aguardando sua vez nas páginas de alocação.”
“Que ferramentas podemos usar para examinar todas essas coisas?” Eu perguntei.
“O SQL Server tinha um criador de perfil para examinar procedimentos armazenados, mas está obsoleto. Algo assim é uma boa maneira de encontrar e diagnosticar consultas de problemas, mesmo que seja apenas o primeiro passo. Depois, há visualizações e funções de gerenciamento dinâmico que ajudam a monitorar a integridade de seu servidor e banco de dados, solucionar problemas e ajustar seu SQL.”
“Mas o SQL Server tem tantas partes móveis”, eu disse. “Prefiro ter uma ferramenta que veja a imagem inteira de fora para dentro.”
"Eu também. De preferência da nuvem, para que não precisemos de mais hardware e software no local para fazer isso."
Alívio de gargalos de desempenho no SQL Server
Pike estava começando a ficar lotado. E, por mais dispostos que o chefe e eu estivéssemos sentados em um pub e conversando, era sexta-feira à noite, afinal. Tínhamos outros lugares para ir, outras pessoas para ver e outras coisas para conversar.
“O que devemos fazer quando encontrarmos os gargalos?” Eu perguntei.
"Nós reunimos os suspeitos de sempre", disse o chefe. “Para evitar usar muita memória, precisamos informar aos desenvolvedores de banco de dados quais de seus códigos e consultas estão vazando memória. Se encontrarmos operações que unem quatro, cinco ou seis tabelas, teremos que dar aos desenvolvedores algumas dicas de ajuste e melhores práticas do SQL Server para redesenhar o banco de dados. Ou podemos ter muitos índices e podemos estar perdendo ciclos atualizando-os; isso é tão difícil para a CPU e E/S quanto ter poucos índices. Podemos ter um problema com a fragmentação do índice do SQL Server ou podemos ter que eliminar os índices obsoletos e duplicados.”
“Faz sentido,” eu disse. “Talvez precisemos jogar mais hardware nele. Discos mais rápidos podem ajudar com gargalos de E/S. CPUs mais e mais rápidas fazem a diferença nos tempos de resposta das consultas. E adicionar RAM significa mais escalabilidade do SQL Server, certo?”
“Sim”, disse o chefe, “mas primeiro quero ter certeza de que a causa raiz não é um problema de desenvolvimento ou DevOps. Quando estiver convencido de que não é, jogarei o cartão Buy More Hardware. ”
Sentamos por um momento e assistimos o pub se encher de foliões de sexta-feira à noite.
“Chefe”, perguntei, “você acha que todas essas pessoas sabem como é uma existência despreocupada que levam, sem o fardo de lidar com sessões bloqueadas, espera máxima de E/S, expectativa de vida da página e taxas de acerto do cache do buffer?”
“É uma cruz para carregar, não é?” o chefe respondeu. “A maioria das pessoas não tem ideia do que passamos. Ainda bem que lidamos com gargalos de desempenho do SQL Server tão silenciosamente, com tanta graça sob pressão e com tanto bom gosto. Falando em bom gosto, como você está indo no seu gargalo?”
Eu chequei. “Meu gargalo está vazio. Assim como minha garrafa.”
"Meu também. Hora de ir. Temos trabalho a fazer.”
É possível um sistema de gargalo zero SQL Server?
Sabemos que existem etapas que podemos tomar para evitar esses três tipos comuns de gargalos do SQL Server. Mas é possível configurar um banco de dados SQL Server tão bem que tenha zero gargalos?
A resposta curta é provavelmente não. Mesmo o DBA mais diligente terá gargalos do SQL Server aparecendo de vez em quando. Mas você pode tomar medidas para evitar gargalos de forma proativa e minimizar seu impacto no desempenho. Por exemplo, Brent Ozar oferece ótimas dicas para monitorar contadores Perfmon para ajustar seu SQL Server, e você pode usar a exibição sys.dm_os_performance_counters para ajudar a identificar gargalos e corrigi-los rapidamente.
Os gargalos do SQL Server são um fato da vida do DBA. Felizmente, com supervisão adequada, monitoramento diligente e ajuste frequente de consultas, os problemas de desempenho podem ser resolvidos antes mesmo que os usuários saibam que há um problema.
