A solução de problemas de desempenho é uma arte e uma ciência. A arte vem da experiência (e do aprendizado com as experiências dos outros) e a ciência vem de diretrizes bem conhecidas sobre o que fazer em quais cenários.
Ou pelo menos é o que gosto de pensar e ensinar.
Na realidade, muitos DBAs e desenvolvedores praticam o que chamo de “solução de problemas de desempenho instintiva”. Isso geralmente acontece quando um problema de desempenho atingiu o estágio crítico com, por exemplo, o tempo limite de consultas, processos lentos ou com falha, usuários insatisfeitos e gerenciamento querendo respostas e ações rápidas!
O 'joelho-empurrão' vem de fazer uma análise superficial do problema e pular para a conclusão (na verdade, é agarrar um canudo) que o sintoma mais prevalente deve ser a causa raiz e tentar resolver isso, com pouco ou nenhum resultado, muitas vezes usando conselhos equivocados ou totalmente incorretos encontrados online. Isso leva a muita frustração e perda de tempo, e muitas vezes leva a desperdício de dinheiro quando a organização decide tentar resolver o problema com hardware atualizando o servidor e/ou o subsistema de E/S, apenas para descobrir que o problema ainda está lá , ou reaparece rapidamente novamente.
A análise de estatísticas de espera é uma das áreas em que é mais fácil fazer uma inflexão, e neste post vou falar sobre alguns dos tipos comuns de espera e os erros que as pessoas cometem ao seu redor. Não há espaço em um artigo como este para se aprofundar sobre o que fazer em cada caso, mas vou lhe dar informações suficientes para apontá-lo na direção certa.
LCK_M_XX
A maioria das pessoas assume que, se as esperas de bloqueio são as mais prevalentes, deve ser algum tipo de problema de bloqueio que é o problema. Geralmente é, como a falta de um índice não clusterizado adequado, causando uma varredura de tabela nos níveis de isolamento REPEATABLE_READ ou SERIALIZABLE que escala para um bloqueio de tabela S. (E como uma dica rápida, se você acha que nunca usa SERIALIZABLE, você usa se usar transações distribuídas – tudo é convertido para SERIALIZABLE nos bastidores, o que pode levar a bloqueios e deadlocks inesperados.)
No entanto, muitas vezes o bloqueio está sendo causado por outra coisa. Sob o nível de isolamento READ_COMMITTED padrão, os bloqueios que cobrem as alterações são mantidos até que a transação seja confirmada e bloquearão leituras e outras atualizações na(s) mesma(s) linha(s). Se alguma coisa impedir que uma transação seja confirmada, isso pode fazer com que o bloqueio apareça.
Por exemplo, se o banco de dados for espelhado de forma síncrona, a transação não poderá confirmar e liberar seus bloqueios até que os registros de log tenham sido enviados para o espelho e gravados na unidade de log do espelho. Se a rede estiver muito congestionada ou houver uma contenção de E/S maciça no espelho, isso poderá atrasar seriamente a operação de espelhamento e, assim, fazer com que a transação demore muito mais para ser confirmada. Isso pareceria um bloqueio, mas a causa raiz é a contenção de recursos relacionada ao espelhamento.
Para esperas de bloqueio, a menos que a causa seja óbvia ao observar o plano de consulta, o recurso de bloqueio (por exemplo, nível de tabela indicando escalonamento de bloqueio ou nível de isolamento, siga a cadeia de bloqueio (usando um script que percorre a coluna blocking_session_id em sys.dm_exec_requests e, em seguida, olhe para ver o que o encadeamento no início da cadeia de bloqueio está esperando. Isso apontará para a causa raiz.
ASYNC_NETWORK_IO
O nome deste causa muita confusão. Em qual palavra você se concentra? REDE. A causa desse tipo de espera geralmente não tem nada a ver com a rede. Deveria realmente se chamar WAITING_FOR_APP_ACK (nowledgement), ou algo semelhante, pois é exatamente isso que está acontecendo:o SQL Server enviou alguns dados para um cliente e está esperando que o cliente reconheça que consumiu os dados.
Uma das minhas demonstrações favoritas ao ensinar sobre estatísticas de espera é executar uma consulta que retorna um grande conjunto de resultados no Management Studio e observar o servidor acumular esperas ASYNC_NETWORK_IO. Claramente, não há rede envolvida – é apenas o SSMS demorando muito para responder ao SQL Server. Ele está fazendo o que é conhecido como RBAR (Row-By-Agonizing-Row), onde apenas uma linha de cada vez é extraída dos resultados e processada, em vez de armazenar em cache todos os resultados e responder imediatamente ao SQL Server e proceder ao processamento do linhas em cache.
Esta é a principal causa de esperas ASYNC_NETWORK_IO – design de aplicativo ruim. Em seguida, veria se o servidor que executa o código do aplicativo tem um problema de desempenho, mesmo que o próprio código do aplicativo seja bem projetado. Ocasionalmente é a rede, mas isso é raro na minha experiência.
OLEDB
A reação instintiva comum aqui é igualar esse tipo de espera com servidores vinculados. No entanto, esse tempo de espera tornou-se mais comum quando o SQL Server 2005 foi lançado, porque 2005 continha uma série de novos DMVs, e os DMVs usam principalmente OLE DB nos bastidores. Antes de procurar problemas de servidor vinculado, eu verificaria se uma ferramenta de monitoramento está executando DMVs constantemente no servidor.
Se você tiver servidores vinculados, continue a solução de problemas acessando o servidor vinculado e verificando as estatísticas de espera para ver qual é o problema mais prevalente e, em seguida, continue a mesma análise.
Uma outra coisa que pode causar esperas OLEDB é DBCC CHECKDB (e comandos relacionados). Ele usa um conjunto de linhas OLE DB para comunicar informações entre seus subsistemas do Processador de Consultas e do Mecanismo de Armazenamento.
Outras esperas
Algumas das outras esperas que causam reações instintivas são CXPACKET, PAGEIOLATCH_XX, SOS_SCHEDULER_YIELD e WRITELOG, e abordarei isso no meu post no próximo mês.
Resumo
Quando você tiver um problema de desempenho, reserve um tempo para entender os dados que você está analisando e realizar investigações adicionais para ajudar a identificar a causa raiz do problema. Não se apegue apenas ao que parece ser a principal estatística de espera e siga o primeiro conselho que você encontrar on-line (a menos que seja de uma fonte conhecida e respeitável) ou você provavelmente não resolverá seu problema e pode até torná-lo pior.
No que diz respeito às estatísticas gerais de espera, você pode encontrar mais informações sobre como usá-las para solucionar problemas de desempenho em:
- Minha série de postagens no blog, começando com as estatísticas do Wait, ou diga-me onde dói
- Minha biblioteca de tipos de espera e classes de trava aqui
- Meu curso de treinamento on-line Pluralsight SQL Server:solução de problemas de desempenho usando estatísticas de espera
- Consultor de desempenho do SQL Sentry
Este foi o primeiro de uma série de posts que farei ao longo deste ano que falam sobre (re)ações automáticas em torno do SQL Server e por que elas são a coisa errada a se fazer. Até a próxima, feliz solução de problemas!
