Início / dba / Perguntas / 35579
Accepted
prog_sr08
Asked: 2013-02-28 04:18:03 +0800 CST

SQL Server 2012 mais lento que 2008

  • 772

Migrei um grande site e banco de dados de um servidor mais antigo (Windows 2008 / SQL Server 2008 / 16 GB de RAM / 2 discos Quad Core / SAS de 2,5 GHz) para um servidor mais novo e muito melhor (Windows 2008 R2 / SQL Server 2012 SP1 / 64 GB de RAM / 2 x 2,1 GHz 16 processadores Core / discos SSD).

Separei os arquivos do banco de dados no servidor antigo, copiei e anexei no novo servidor. Tudo correu muito bem.

Depois disso, mudei para o nível de compatibilidade para 110, atualizei estatísticas, reconstruí índices.

Para minha grande decepção, notei que a maioria das consultas sql são muito mais lentas (2-3-4 vezes mais lentas) no novo servidor SQL 2012 do que no antigo servidor SQL 2008.

Por exemplo, em uma tabela com cerca de 700k registros, no servidor antigo uma consulta no índice levava cerca de 100ms. No novo servidor, a mesma consulta demora cerca de 350 ms.

O mesmo acontece para todas as consultas.

Gostaria de uma ajuda aqui. Deixe-me saber o que verificar/verificar. Porque acho muito difícil acreditar que em um servidor melhor com um SQL Server mais recente, o desempenho seja pior.

Mais detalhes:

A memória está configurada para max.

Eu tenho esta tabela e índice:

CREATE TABLE [dbo].[Answer_Details_23](
    [ID] [int] IDENTITY(1,1) NOT NULL,
    [UserID] [int] NOT NULL,
    [SurveyID] [int] NOT NULL,
    [CustomerID] [int] NOT NULL default 0,
    [SummaryID] [int] NOT NULL,
    [QuestionID] [int] NOT NULL,
    [RowID] [int] NOT NULL default 0,
    [OptionID] [int] NOT NULL default 0,
    [EnteredText] [ntext] NULL,
 CONSTRAINT [Answer_Details_23_PK] PRIMARY KEY NONCLUSTERED 
(
    [ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

CREATE NONCLUSTERED INDEX [IDX_Answer_Details_23_SummaryID_QuestionID] ON [dbo].[Answer_Details_23]
(
    [SummaryID] ASC,
    [QuestionID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

Eu executei esta consulta:

set statistics time on;
select summaryid, count(summaryid) from Answer_Details_23 group by summaryid order by count(summaryid) desc;
set statistics time off;

OLD SERVER - Tempos de execução do SQL Server: tempo de CPU = 419 ms, tempo decorrido = 695 ms.

NOVO SERVIDOR - Tempos de execução do SQL Server: tempo de CPU = 1340 ms, tempo decorrido = 1636 ms.

PLANOS DE EXECUÇÃO carregados aqui: http://we.tl/ARbPuvf9t8

Atualização posterior:

  • Os processadores AMD Opteron 16 core de 2,1 GHz parecem muito piores do que os processadores quad core Intel de 2,5 GHz
  • Grande melhoria mudando as opções de energia do Windows de balanceado para alta potência
  • Melhoria adicional alterando o grau máximo de paralelismo para 8 e o limite de custo para 4

Agora, Tempos de Execução do SQL Server: Tempo de CPU = 550 ms, tempo decorrido = 828 ms.

Ainda é pior que o servidor antigo, mas não tão ruim. Se você tiver outras sugestões (além de otimizações de consultas locais), sinta-se à vontade para comentar.

sql-server performance

6 respostas

  1. Deixe-me saber o que verificar/verificar

    Você tem um problema de desempenho. Siga uma metodologia de solução de problemas de desempenho, como Esperas e Filas, para identificar o gargalo. A metodologia vinculada mostra o que medir e como. Publique aqui as descobertas e podemos ajudar com conselhos específicos com base em suas medições reais. Como é é muito aberto e é uma incógnita. Limitá-lo a um problema específico eliminará as suposições.

    Após atualização

    Os planos são bem diferentes. O plano antigo tinha um agregado de fluxo baixo na pilha que na verdade tem uma estimativa de cardinalidade ruim (141k vs. 108k) e a matemática de hash prediz ainda mais mal, ao contrário (35k vs. 108k). O novo plano não tem o fluxo agregado e tem estimativas precisas até o topo. Obviamente, isso não explica por que o plano antigo estava sendo executado mais rapidamente .

    As varreduras inferiores têm um número de linhas ligeiramente diferente (não significativo), mas custos bastante diferentes: o antigo é 2,49884 (IO 2,28979 CPU 0,20905) versus o novo 1,59109 (IO 1,53868 CPU 0,0524084). Novamente apontaria para uma melhor execução de 2012 (a reconstrução do índice talvez tenha reduzido a fragmentação?).

    O que é muito diferente é o número de threads: 32 em novos (cada um recebendo ~ 23k linhas) versus 8 em antigos (cada um recebendo ~ 95k linhas). A mesa é bastante estreita. Pode ser que o grande número de threads esteja realmente prejudicando o desempenho por causa de invalidações de cache muito mais freqüentes . Eu tentaria:

    1. eliminar o HyperThreading na nova configuração do servidor (se houver) e/ou
    2. tente a consulta com um DOP 8.

    Percebi seu comentário:

    Adicionado o plano de execução com maxdop 8 Query é realmente mais rápido dessa maneira

    Provavelmente são apenas CPUs pisando nos dedos uns dos outros. Com os SSDs instalados, o IO provavelmente é quase nada e a mesa é definitivamente pequena demais para garantir 32 scanners. Essa troca de câmbio provavelmente está invalidando L1/L2 constantemente.

    • 8
  2. Best Answer

    Eu tive problemas semelhantes com o SQL Server, é possível que seu servidor não esteja configurado de maneira ideal. Os Xeons mais recentes vêm com TurboBoost, HT, etc. que podem afetar significativamente o desempenho do servidor.

    Por exemplo, tivemos sucesso com; Configuração de baixa latência para servidores Dell

    As configurações serão aplicáveis ​​a servidores que não são da Dell, mas eles podem ter nomes diferentes.

    Também melhoramos o desempenho definindo o perfil de gerenciamento de energia do Windows para alto desempenho, de Balanceado. Uma parte final é que é recomendável reservar até 8 GB de memória para o sistema operacional em servidores x64, a instalação padrão do SQL ocupa toda a memória. Você pode tentar a reserva de 4/8 GB definindo sua configuração máxima de memória do SQL Server para 4/8 GB a menos que a memória total.

    Minha recomendação seria reverter para o servidor antigo, se possível. Se você não tiver scripts de regressão/automação/carregamento disponíveis, o melhor que você pode fazer é registrar a atividade do sistema por 1-4 horas durante um período de alta atividade. Em seguida, configure um servidor web igual ao de produção e uma máquina cliente para executar o script. Execute a mesma atividade no novo servidor, altere a configuração e execute a mesma atividade novamente. Realmente você gostaria de fazer muito mais, mas não parece que seria viável e está fora do escopo desta questão.

    • 8

  3. Para a maioria dos sistemas multinúcleo modernos, e particularmente os sistemas com várias CPUs, a arquitetura de hardware é tal que certas partes da memória estão longe de certos núcleos/processadores e certas partes da memória estão próximas de certos núcleos/processadores. Isso é conhecido como Arquitetura de Memória Não Uniforme, ou NUMA para abreviar. Você deseja que sua configuração MAXDOP corresponda ao número de núcleos por nó NUMA para minimizar o número de vezes que um determinado nó numa precisa sair de sua própria memória para dados.

    Você pode usar o seguinte para verificar a configuração de sua nova máquina e garantir que MAXDOP esteja definido com a melhor configuração, em termos de hardware :

    DECLARE @CPUs int;
DECLARE @NumaNodes int;
DECLARE @ServerRAMInMB int;

SET @ServerRAMinMB = (SELECT (i.physical_memory_kb / 1024) AS ServerMemory 
    FROM sys.dm_os_sys_info i);
SET @CPUs = (SELECT i.cpu_count from sys.dm_os_sys_info i);
SET @NumaNodes = (SELECT MAX(c.memory_node_id) + 1 FROM sys.dm_os_memory_clerks c 
    WHERE memory_node_id < 64);

SELECT @ServerRamInMB, @CPUs, @NumaNodes;

IF @CPUs > 4 /* this would be 4 cores, not 4 CPUs */
BEGIN
    DECLARE @MaxDOP int;
    SET @MaxDOP = @CPUs * 0.75;
    IF @MaxDOP > (@CPUs / @NumaNodes) SET @MaxDOP = (@CPUs / @NumaNodes);
    EXEC sp_configure 'max degree of parallelism', @MaxDOP;
    EXEC sp_configure 'cost threshold for parallelism', 4; 
END

    Incluí o @ServerRamInMBparâmetro aqui, pois o uso para configurar as opções de configuração Max Server Memorye Min Server Memoryos valores apropriados para o servidor fornecido.

    • 3

  4. Em qual edição e modo de licenciamento você está? Você provavelmente não está usando todos os núcleos. Veja a nota nesta página - http://msdn.microsoft.com/en-us/library/ms143760.aspx

    "Enterprise Edition com licença baseada em Server + Client Access License (CAL) é limitada a um máximo de 20 núcleos por instância do SQL Server."

    • 0

  5. Eu tive o mesmo problema descrito nesta página: mudar as configurações de energia de "balanceado" para "alto desempenho" fez uma diferença dramática - mais do que dobrando os tempos de resposta. Agora que estamos usando SSDs, não acho que o consumo de energia seja o problema que possa ter sido.

    • 0

  6. Também passei por esse problema por pelo menos 2 semanas sem nenhuma resolução robusta, em vez de confundir um problema com o outro.

    Finalmente a resolução da seguinte forma: -

    1. Eu resetei a compatibilidade de 010 para 011

    2. Redefina a compatibilidade do banco de dados mestre também. Por padrão, o sql manterá a configuração de compatibilidade antiga. Que precisamos mudar manualmente.

    Tudo de bom

    • -2

relate perguntas