Portanto, temos usado um servidor de banco de dados robusto há pouco mais de 7 anos. No ano passado, começamos a mudar para um novo servidor que é essencialmente melhor em todos os aspectos, fazendo a transição de um banco de dados por vez. Há um banco de dados em particular que mudamos para o novo servidor e as coisas ficaram ruins...
Mesmo sob carga baixa a moderada, as consultas começaram a atingir o tempo limite, o desempenho neste banco de dados e em outros que já haviam sido transferidos era visivelmente mais lento em quase todos os aspectos até fazermos a transição de volta para o servidor original. Depois disso, o desempenho no novo servidor se estabilizou e o banco de dados com problemas ficou bom no servidor original.
Alguns detalhes seriam úteis!
Especificações do nosso servidor atual (envelhecido):
- Dell PowerEdge T640
- Processador duplo Intel Xeon Gold 5120 (2,20 GHz, 56 núcleos no total)
- 512 GB de RAM
- NVMe RAID 1 para C (SO), HDD RAID 10 [8 discos] para D (dados SQL), SSD RAID 1 para L (logs SQL), SSD RAID 1 para T (TempDB)
- Centro de dados do Windows Server 2016
- SQL Server 2019 Empresarial
Especificações do nosso novo servidor:
- Dell PowerEdge R7515
- Processador único AMD EPYC 7H12 (2,6 GHz, 64 núcleos no total)
- 1024 GB de RAM
- NVMe RAID 1 para C (SO), SSD RAID 10 [10 discos] para D (dados SQL), SSD RAID 1 para L (logs SQL), NVMe RAID 1 para T (TempDB)
- Padrão do Windows Server 2022
- SQL Server 2019 Empresarial
Configuração do SQL Server
A configuração do servidor é quase idêntica, exceto onde faz sentido devido a variações de hardware (Max RAM). Aqui estão as capturas de tela:
*Ativar bancos de dados independentes não está habilitado no novo servidor, no entanto, não utilizamos esse recurso.
**Antes de começarem os comentários, percebi que o CTFP é ultrajante, isso é outra bola de cera.
Em particular, ao revisar nossas ferramentas de monitoramento, notamos valores desproporcionais ao comparar as seguintes métricas obtidas em sys.dm_os_performance_counters:
- Transações
- Solicitações de bloqueio/s
- Tempo limite de bloqueio/s
- Tempo médio de espera de travamento (ms)
Fico feliz em fornecer detalhes/gráficos adicionais se isso ajudar.
O banco de dados em questão tem um tamanho decente, mas é grande para nós (120 GB), mas possui muitos gravadores ativos em uma aplicação OLTP. Existem muitas divisões de páginas envolvidas neste banco de dados em particular.
Academicamente, tudo sobre o novo servidor deve ser capaz de lidar com a carga do servidor antigo e muito mais.
Todas essas informações para fazer estas perguntas:
- Há alguma diferença em como os bloqueios, travas ou divisões de página são tratados em um processador AMD versus Intel?
- Existe alguma diferença em como bloqueios, travas ou divisões de página são tratados em um soquete único e em vários soquetes?
- Existem estruturas de dados SQL que podem se comportar de maneira diferente entre os servidores? (este é o único banco de dados que usamos índices de armazenamento de colunas, índices filtrados e algumas outras construções mais recentes/sofisticadas para ajudar a acelerar as coisas)
- Existem outros fatores que deveriam fazer com que um banco de dados se comportasse de maneira tão diferente de servidor para servidor?
Agradecemos antecipadamente por se juntar a mim na loucura!
ATUALIZAÇÃO 1
Executamos o incrível script SQL Server Index and Statistics Maintentnce de Ola Hallengren todas as noites, reorganizando cada tabela com 5% de fragmentação e reconstruindo com 30% de fragmentação E atualizando as estatísticas INDEX. Isso é executado pelo SQL Agent em cada servidor sem erros.
ATUALIZAÇÃO 2
Depois de dedicar algum tempo para desenvolver maneiras de replicar a carga que estávamos definindo sem impactar o cliente, começamos a testar várias teorias. O vencedor foi @StrayCatDBA que deu o call com as configurações de energia. As opções de energia balanceadas acabaram estacionando muitos de nossos núcleos, o servidor nunca estava sob carga suficiente para superar esse afogamento, mas foi o suficiente para fazer com que o servidor lutasse o suficiente para impactar as cargas de trabalho.
Agradeço a todos que dedicaram algum tempo e colaboraram. Alguns dos comentários foram úteis no curto prazo e alguns deles ajudaram a iniciar o processo de refatoração de algumas de nossas consultas mais "agressivas" (e as práticas necessárias para compensar) .
Confirme se as configurações de energia estão definidas como "alto desempenho", especialmente em máquinas com um grande número de CPUs.
A configuração de energia "equilibrada" irá desacelerar as CPUs para economizar energia e, em teoria, desacelerá-las sob carga. Em uma caixa de 64 CPUs, 10 CPUs a 100% representam apenas ~15% da carga geral, o que pode não ser suficiente para desacelerar as coisas.
Esse comportamento resulta em um desempenho horrível para consultas únicas com cargas muito baixas.