Temos vários servidores db em produção, 4 deles com configuração de hardware muito semelhante. Dell PowerEdge R620, a única diferença é que os 2 mais novos (comprados e configurados há 3 meses) têm o controlador RAID v710, 256 GB de RAM e CPU são 2 Xeon E5-2680 2.80GHz físicos. Os antigos (comprados e configurados há cerca de um ano atrás) têm o controlador RAID v700, 128GB de RAM e rodam no witl 2 Xeon E5-2690 2.90GHz físico. O BIOS é atualizado, todos os drivers são atualizados para as últimas versões, etc. Todos os SQL Server 2008R2 Enterprise (SP1) em execução são atualizados para a última CU e o Windows 2012R2 Standard. Ambos rodando no SSD de 200 GB x5 RAID10. Há apenas um banco de dados em execução em cada um deles, sincronizado usando um trabalho que chama um pacote SSIS. Nosso administrador de sistema executou muito desempenho e teste de estresse para garantir que não temos nenhuma configuração ou falha de falta de hardware ou de rede. Como esperado, os mais novos mostram melhores resultados de desempenho. Por enquanto, tudo bem.
O problema que temos pode ser visto na captura de tela do Kibana. Amarelo e laranja são os 2 servidores mais recentes (6,7 nas tabelas) e abaixo de todos os outros servidores. É perfeitamente visível que esses 2 novos servidores têm um tempo de resposta mais lento. E não apenas isso, mas também esses 2 servidores têm um pouco menos de carga do que os 2 mais antigos (linhas azuis claras e escuras - 4,5 nas tabelas).
Tenha alguns scripts de monitoramento coletando informações nos contadores de desempenho. Se você cavou o mais longe possível com as DMVs e as terceira ferramentas de monitoramento, tenho muitas informações em mãos. Mas deve haver (ofc) algo que estou perdendo aqui, pois não consigo encontrar uma resposta para esse tempo de resposta mais lento.
Os 2 servidores mais recentes estão usando menos RAM, mas acho que isso é esperado, quando comparado aos outros mais antigos, pois eles têm uma carga menor.
| Server Name| Mem_MB | Mem_GB | Server_RAM_GB | SQL_max_mem_GB| SQL_min_mem_GB |
|------------|--------|--------------|---------------|---------------|----------------|
| 4 | 41108 | 40.145263671 | 128 | 120 | 16 |
| 5 | 61272 | 59.836425781 | 128 | 120 | 16 |
| 6 | 34117 | 33.317626953 | 256 | 250 | 16 |
| 7 | 33764 | 32.972656250 | 256 | 250 | 16 |
Mais configuração de RAM para todos os servidores é a seguinte:
| Server Name | Total_Page_File_In_MB | Available_Page_File_MB | Kernel_Paged_Pool_MB | Kernel_Nonpaged_Pool_MB |
|-------------|-----------------------|------------------------|----------------------|-------------------------|
| 4 | 180160 | 130042 | 249 | 98 |
| 5 | 148416 | 77246 | 249 | 110 |
| 6 | 301010 | 260453 | 132 | 99 |
| 7 | 301010 | 260454 | 143 | 108 |
A execução da consulta a seguir em todos os servidores mostra parâmetros de configuração idênticos:
SELECT * FROM master.sys.configurations
Eu poderia continuar mostrando muito mais informações, mas não tenho certeza do que poderia ser necessário. Alguma pista sobre o que devo verificar?
Eu li um white paper conhecido do Microsoft Solucionando problemas de desempenho no SQL Server 2008 e recebi muitas consultas do DMV a partir daí.
EDITAR A pedido:
EXEC sp_configure 'max server memory (MB)'
| Server Name | name | minimum | maximum | config_value | run_value |
|-------------|------------------------|---------|------------|--------------|-----------|
| 4 | max server memory (MB) | 16 | 2147483647 | 120000 | 120000 |
| 5 | max server memory (MB) | 16 | 2147483647 | 120000 | 120000 |
| 6 | max server memory (MB) | 16 | 2147483647 | 250000 | 250000 |
| 7 | max server memory (MB) | 16 | 2147483647 | 250000 | 250000 |
Quanto a maxdop
nós estamos brincando com ele e os resultados são:
EXEC sp_configure 'max degree of parallelism'
| Server Name | name | minimum | maximum | config_value | run_value |
|:-----------:|:-------------------------:|:-------:|:-------:|:------------:|:---------:|
| 4 | max degree of parallelism | 0 | 1024 | 1 | 1 |
| 5 | max degree of parallelism | 0 | 1024 | 1 | 1 |
| 6 | max degree of parallelism | 0 | 1024 | 1 | 1 |
| 7 | max degree of parallelism | 0 | 1024 | 1 | 1 |
Respostas:
Esta imagem diz tudo.
Obrigado Kin por apontar sua pergunta e respostas relacionadas. Eu aprendi muito no processo. Ao analisar sua pergunta detalhada, pensei em fazer o mesmo, comparando os planos de execução de nossa consulta mais pesada ... e pronto! O problema era que um trabalho que deveria estar em execução já havia algumas semanas com o cronograma desativado. Agora devo verificar por que ele foi desativado e quando exatamente foi desativado. Tudo está funcionando sem problemas agora. A linha azul é um servidor que não está recebendo solicitações devido à manutenção, não está morto.
fonte