Usuário com melhor resposta
Baixa Performance SQL em VM no Windows Azure

Pergunta
-
Boa Tarde!
Prezados,
Não sei se é aqui nesse local que devo fazer a pergunta, caso não seja favor informar local correto.
Sou gestor de infraestrutura de uma empresa de desenvolvimento que me solicitou a criação de um ambiente no Windows Azure.Subimos uma VM no Windows Azure com Sql Server Embarcado, upamos nosso banco de 11Gb e quando eles fizeram um teste para contar os registros com o comando Count() levou 60 seg para responder, consultei outros colegas da área de desenvolvimento e eles me disseram que por mais que servidor seja fraco a resposta para esse comando leva 1seg.
Antes disso estavamos usando software como serviço porém não teve boa performance, fomos aconselhados a ter uma VM com SQL que seria melhro performático.
Estamos querendo sair de um DataCenter para o Azure.
E no intuito de descobrir se esse problema é hardware ou banco, levamos essa base para o servidor no datacenter onde está rodando atualmente o mesmo comando foi executado e houve o mesmo problema no comando Count() levou mais de 60seg para retornar. Foi feita uma desfragmentação do banco em seguida rodamos o comando aí levou menos de 1seg.
Então voltamos com essa base para o Azure fizemos a desfragmentação lá aí levou 40 seg ainda um tempo muito ruim.
Alguém tem condições de me dar um norte nesse assunto?
Desde já agradeço
Respostas
-
Flavio, boa tarde.
Apenas para contribuir, levando em conta a questão da infraestrutura no Azure, você provisionou essa VM com Standard Storage? Um Standard Storage tem limite de 500 IOPS por VM e você pode ter até 40 VMs no mesmo storage (20.000 IOPS no final). Eu utilizei SQL Server em VM para realizar testes com System Center, o desempenho não é uma maravilha, funciona, mas tem que levar em conta que a base era pequena, o que não gerava tantos problemas de desempenho. Eu sugiro que você avalie essa questão e faça um teste com Premium Storage que pode chegar a 5.000 IOPS por VM, utiliza disco SSD, mas é bem mais caro também. Dá uma olhada nesses links abaixo:
https://azure.microsoft.com/pt-br/documentation/articles/storage-premium-storage-preview-portal/
https://azure.microsoft.com/pt-br/documentation/articles/azure-subscription-service-limits/
Qualquer dúvida, avise.
Se a resposta fornecida nessa thread ajudou na sua solução, não esqueça de marcar como resposta!
Abraço,
Gustavo Zimmermann Montesdioca - MTAC, MCT
Blog: www.gm9.com.br
- Editado GustavoZimmermannMicrosoft employee sexta-feira, 29 de janeiro de 2016 16:15
- Marcado como Resposta Junior Galvão - MVPMVP, Moderator terça-feira, 2 de fevereiro de 2016 11:56
Todas as Respostas
-
-
-
Flavio, boa tarde.
Apenas para contribuir, levando em conta a questão da infraestrutura no Azure, você provisionou essa VM com Standard Storage? Um Standard Storage tem limite de 500 IOPS por VM e você pode ter até 40 VMs no mesmo storage (20.000 IOPS no final). Eu utilizei SQL Server em VM para realizar testes com System Center, o desempenho não é uma maravilha, funciona, mas tem que levar em conta que a base era pequena, o que não gerava tantos problemas de desempenho. Eu sugiro que você avalie essa questão e faça um teste com Premium Storage que pode chegar a 5.000 IOPS por VM, utiliza disco SSD, mas é bem mais caro também. Dá uma olhada nesses links abaixo:
https://azure.microsoft.com/pt-br/documentation/articles/storage-premium-storage-preview-portal/
https://azure.microsoft.com/pt-br/documentation/articles/azure-subscription-service-limits/
Qualquer dúvida, avise.
Se a resposta fornecida nessa thread ajudou na sua solução, não esqueça de marcar como resposta!
Abraço,
Gustavo Zimmermann Montesdioca - MTAC, MCT
Blog: www.gm9.com.br
- Editado GustavoZimmermannMicrosoft employee sexta-feira, 29 de janeiro de 2016 16:15
- Marcado como Resposta Junior Galvão - MVPMVP, Moderator terça-feira, 2 de fevereiro de 2016 11:56
-
-
Flávio,
Perfeito. Para atualizar as estatísticas desta base de dados você pode utilizar o comando abaixo.
Observação: Não utilize este comando durante os horários críticos do seu sistema. Tente utilizá-lo em uma janela de manutenção adequada.
USE [nomeDatabase] GO EXEC sp_updatestats GO
Felipe Lauffer MCSA: SQL Server | MCP
- Editado FLauffer sexta-feira, 29 de janeiro de 2016 17:48
-
-
-
Boa tarde Flavio,
Como Flauffer mencionou não é recomendado executar em produção sem uma janela, essa procedure atualiza todas as estatísticas do banco de dados em que esta sendo executado.
Todas as consultas do SQL Server é baseado em custo, para calcular esse custo SQL se baseia nas estatísticas que são criadas automaticamente pelo SQL ou manualmente, conforme o numero de transações em seu banco essas estatísticas vão ficando desatualizas podendo gerar planos de execuções ruins em suas querys, como pode ver esse seu caso, então é recomendado montar uma estrategia para estar sempre atualizando essas estatísticas e desfragmentando índices mais usados de preferencia em horários que não causaram impacto na produtividade.
Att
Reginaldo Silva
-
Não estou fazendo no banco de produção.
Para efeito de manutenção é válido.
Independentemente, você acha que consigo resolver essa questão em específico da primeira query, são 14.000.000 de registros você acha são muitos registros?
- Editado Flávio Henrique Fontes sexta-feira, 29 de janeiro de 2016 20:04