Por que meu SQL Server do Azure é tão lento?

10

No momento, temos uma VM com pouca potência e estamos propondo mudar para uma VM do Azure com melhores especificações. O problema é que a VM do Azure é muito mais lenta que a VM original, embora seja uma especificação mais alta.

O servidor original é uma VM de 2 núcleos com 2 GB de memória que também é um servidor da web. Ele está executando o Microsoft SQL Server Web Edition 2008 R2 e, como esse servidor é usado para outras coisas, tivemos que limitar a memória máxima do servidor no SQL Server para 512 MB .

O novo servidor é uma VM de 4 núcleos com 7 GB de memória que é apenas um servidor de banco de dados. Ele está executando o Microsoft SQL Server Standard Edition 2008 R2 e não limitamos a quantidade de memória que o SQL Server pode usar.

Este é um dos dois servidores configurados em um ambiente espelhado, mas o banco de dados em que estou executando testes não é espelhado. Os outros bancos de dados neste servidor não estão recebendo muito tráfego no momento (na verdade, o Activity Monitor não mostra atividade nos outros bancos de dados enquanto eu executava esses testes).

Percebo que um problema nas VMs do Azure é que os discos rígidos são um recurso de rede, o que seria a fonte de lentidão, mas ainda é mais lento mesmo quando há 0 leituras físicas mostradas nas estatísticas de E / S.

Eu segui os conselhos de ajuste nesta página na VM do Azure, incluindo a distribuição dos discos (dois discos por unidade) e a colocação dos arquivos de log e dados em unidades separadas.

As únicas coisas que não fiz foram habilitar a compactação de páginas, limitar o crescimento automático no banco de dados e mover o log de erros do SQL Server e rastrear os diretórios dos arquivos em discos de dados. Também não fiz isso no servidor antigo.

O servidor antigo não realiza nada desse ajuste e os arquivos de log e dados estão na mesma unidade que não está distribuída.

O banco de dados no servidor atual é de 65 GB (45 dados e 20 log), que era um pouco grande demais para ser transferido para o novo servidor, por isso estou testando em um banco de dados menor (6 dados e 13,5 log)

Os resultados no servidor antigo são CPU time = 1311 ms, elapsed time = 1057 ms.e no novo servidor são CPU time = 1281 ms, elapsed time = 2525 ms. Isso é apenas uma execução, mas os resultados são representativos do que eu estou vendo normalmente.

O novo servidor parece ter constantemente um tempo decorrido significativamente maior que o tempo da CPU. Isso é um problema e há algo que eu possa fazer para rastrear o que está causando isso?

Que outras etapas posso executar para descobrir por que esse servidor está indo tão lentamente quando parece que deve ser mais rápido que o servidor antigo?

Steve Kaye
fonte
11
Maxdop 1? Você comparou os planos de execução, tirou as estatísticas de antes e depois da espera e verificou o bloqueio?
Aaron Bertrand
11
Quantas unidades de dados? Com o armazenamento de blob de página padrão, cada unidade é limitada a menos de 300 IOPS na camada básica ou 500 no padrão, que é muito menos do que um disco giratório no local. É imperativo ter o maior número possível de unidades (vhd) para maximizar o IOPS e a largura de banda. Você pode usar os Espaços de armazenamento do Windows para evitar a necessidade de criar um arquivo de dados separado em cada unidade.
Dan Guzman
O novo servidor possui 4 VHDs distribuídos em duas unidades, por isso tenho 1000 IOPS para logs e 1000 IOPS para dados.
Steve Kaye
Um VHD de armazenamento de blog de página padrão fornece apenas cerca de 30 MB / s de largura de banda devido à limitação, o que significa apenas 60 MB / s de agregação. Considere criar 14 VHDs de dados para até 420MB / seg e distribuir entre todos.
Dan Guzman
Eu só posso ter 8 discos, pois é uma instância A3, então eu precisaria fazer o upgrade para A4 para fazer o dobro do preço. Eu não acho que isso seja um problema de unidade, já que os testes acima de tudo tinham 0 leituras físicas listadas nas estatísticas de E / S.
Steve Kaye

Respostas:

2

Pelo que vale, terminei de alterar a VM no Azure do tipo A para o tipo D e, em seguida, anexar outro disco e mover o TEMPDB para esse disco. Portanto, minha VM final agora é um padrão D2 com 7 GB de RAM e três discos de dados, um para os arquivos MDF, outro para arquivos LDF e o novo disco TEMPDB.

Desisti de tentar entender com o A3 algumas coisas que você mencionou e simplesmente atualizou a máquina virtual. Até fui de A2 para A3 e, apesar de encontrar algumas melhorias, acabei mudando para uma VM D2.

No documento que você declarou, a Microsoft recomenda um D3 para Enterprise Edition ou D2 para Web ou Standard Edition e o uso do Armazenamento Premium, entre outras coisas na lista de verificação no início do documento.

Guillermo Taylor
fonte