Problema de Desempenho SQL IA64

Question

Temos um problema de desempenho na produção.

Os ambientes QA e DEV são duas instâncias no mesmo servidor físico: Windows 2003 Enterprise SP2, 32 GB de RAM, 1 Quad de 3,5 GHz Intel Xeon X5270 (4 núcleos x64), SQL 2005 SP3 (9.0.4262), unidades SAN

Prod: Windows 2003 Datacenter SP2, 64 GB de RAM, 4 Família Intel Dual Core 1.6 GHz 80000002, Modelo 6 Itanium (8 núcleos IA64), SQL 2005 SP3 (9.0.4262), unidades SAN, Cluster Veritas

Estou vendo percentuais excessivos de espera de sinal (> 250%) e leituras de páginas / s (> 50) e gravações de página / s (> 25) são altos ocasionalmente.

Eu testei essa consulta no QA e no PROD e ela tem o mesmo plano de execução e as mesmas estatísticas:

SELECT 
                top 40000000 * 
INTO 
                dbo.tmp_tbl
FROM
                dbo.tbl
GO

Número de varreduras 1, leituras lógicas 429564, leituras físicas 0, leitura antecipada lê 0, leituras lógicas de lóbulo 0, leituras físicas de lóbulo 0, leitura adiantada lob lê 0.

Como você pode ver, são apenas leituras lógicas, no entanto: QA: 0:48 Prod: 2:18

Portanto, parece um problema relacionado com o processador, mas não tenho a certeza para onde ir em seguida, alguma ideia?

Obrigado,

Aaron

    

Answer 1

Isso foi causado por dois problemas - índices diferentes entre prod e QA junto com o maxdop configurado incorretamente.

    

Answer 2

Havia mais alguma coisa acontecendo no servidor Prod? Parece que o servidor de controle de qualidade tinha apenas essa consulta para executar, enquanto o sistema Prod tinha que contentar-se com CPU com outras consultas em execução ao mesmo tempo. Como os elapsed_time e o worker_time se comparam no controle de qualidade e produção?

Além disso, verifique se os planos são exatamente idênticos, incluindo o DOP.

    

Answer 3

Eu tenho algumas sugestões de coisas que você pode investigar na SAN:

• Você está vendo uma trava de E / S de página significativa aguardando na SAN de produção?

• Os logs do banco de dados estão em um volume compartilhado ocupado?

No primeiro caso, pode haver uma configuração da SAN ou outro problema de desempenho relacionado aos controladores da SAN. Eu vi isso acontecer no hardware de tubarão da IBM; mudar para um DS8000 reduziu substancialmente o problema.

No último caso, você pode estar tendo problemas com a busca aleatória para interromper a atividade de gravação de log. As gravações de log são, na maioria das vezes, um processo sequencial com um grande número de pequenas gravações seqüenciais. Em discos silenciosos, isso é rápido, pois os padrões de acesso ao disco são na maior parte seqüenciais. Nos discos ocupados, o outro tráfego de disco transforma as gravações de log seqüenciais em gravações aleatórias, que são muito mais lentas. Isso pode transformar as unidades de log em um gargalo de desempenho significativo.

Observe que o SQL Server exige que as gravações de log sejam liberadas para o disco antes que uma transação seja confirmada, e a maioria dos fornecedores de SAN tenha se inscrito em um programa de certificação, garantindo que os controladores honrem esse padrão. Isso significa que nenhuma quantidade de memória cache atenuará esse problema se seus logs residirem em um volume compartilhado ocupado.

    

Answer 4

"Então parece um problema relacionado ao processador, mas não tenho certeza para onde ir em seguida, alguma idéia?"

Não parece razoável para mim que um CPU de arquitetura Core 2 de 3,5 GHz seja talvez 100% mais rápido do que um Itanium de 1,6 GHz (a família Itanium 2, Fanwood ou Madison não é a família Intel 80000002 original?). Se você precisar de mais velocidade, veja uma atualização da CPU, talvez para um Xeon da série x5600.