O que pode causar longos períodos de consulta sem alto uso de recursos?

4

Antecipadamente: desculpe pela duração da pergunta ... incapaz de obter o equilíbrio certo entre detalhe e brevidade.

Estamos tendo problemas com o DB Server para o nosso aplicativo web, onde as consultas que devem (e geralmente são) executadas em um tempo muito curto (< 10ms) são, em ocasiões aleatórias, de 1 a 30 segundos para serem executadas - sem padrão óbvio. De acordo com nossos rastreadores de profiler, alguns deles são até mesmo consultas "do-nothing", como "exec sp_reset_connection" (geralmente executado em 0ms; picos observados de 3 ~ 6s) e "SET NO_BROWSETABLE ON" , etc. Alguns exemplos são:

SELECT * FROM [Localisation].[TimeZoneRule] WHERE [Name] = 'EU'

Em que TimeZoneRule tem cerca de 500.000 linhas em 5 colunas. Tem uma chave primária substituta e um índice em Name . Geralmente leva 0,97 ms, picos em 11s. A tabela NUNCA foi escrita para (foi pré-preenchida antes da entrada em funcionamento). O Profiler registra como tendo de 0 a 15 CPU, 18 a 25 leituras, 0 a 1 gravações (não tem idéia do motivo da gravação).

UPDATE [Core].[User] SET [LastUsed] = GETUTCDATE() WHERE Id = '<uid>'

Em que User tem cerca de 30.000 linhas em cerca de 10 colunas (uma delas é uma coluna Xml). Id é a chave primária em cluster. A tabela é escrita e lida regularmente. Geralmente leva 10 ~ 20ms, picos em 26s. O Profiler registra como tendo 0 CPU, 15-36 leituras, 0-1 gravações.

INSERT INTO [Log].[Session] (ASPSessionId, Start, ClientAddress, ClientSoftware, ProxyAddress, ProxySoftware)
   VALUES(<number>, GETUTCDATE(), '<ipv4address>', '<User agent string>', '<ipv4address>', '<proxy software name (if present)>')

Em que Session tem cerca de 1.000.000 linhas em cerca de 8 colunas. Tem uma chave primária (identidade) substituta e um índice em ASPSessionId . A tabela é escrita regularmente, mas raramente é lida (somente por nós diretamente do SSMS). Geralmente leva 15 ~ 150ms, picos a 5s. Eu não tenho o registro do perfil disponível, mas da memória, a CPU está em torno de 0, as leituras e gravações estavam entre 0 e 100 cada.

A configuração que estamos usando é uma configuração espelhada com um Dell 2950 como princípio (2 4-core xeon 2.6, 16Gb RAM) e um Dell 6850 como espelho (4 HT Xeon 3.2, 8Gb RAM). Ambos executando o SQL 2005 SP4 de 64 bits. O banco de dados em questão não é particularmente grande, com cerca de 16 GB de tamanho. O primário possui 6 discos SAS divididos em 3 volumes RAID-1; uma para System + Page + TempDB, uma para o MDF do banco de dados e outra para o log de transações + backup de log por hora + backup diário de banco de dados. Eu sei que a situação do log está longe de ser a melhor - em termos de disco IO (veja abaixo) e segurança de dados.

Até agora, nós achamos que eliminamos:

  • O espelho. Separamos os servidores e rodamos usando um deles (e depois trocamos para o outro), mas os problemas de desempenho permaneceram.
  • Bloqueio devido a bloqueios (*). TimeZoneRule nunca é gravado e, por minha conta, nunca deve ter um bloqueio exclusivo sobre ele. Além disso, verificamos os rastreios e, em muitas ocasiões, a "consulta com problema" é a única em execução - a única outra atividade é a desconexão de outras conexões
  • Má indexação. Com os números baixos para leituras e CPU, sugeriria que o SQL Server está usando índices de maneira eficaz.
  • Disco IO. O PerfMon indica alguns valores ímpares para a unidade de arquivo de dados (mas apenas essa unidade) - embora as taxas de leitura / gravação de dados raramente excedam 32 KB / s, o Comprimento Atual da Fila de Disco aumenta para cerca de 215 para durações de 2-5 segundos a aproximadamente 45 -Intervalos de 60 minutos sem padrão fixo. No entanto, eles não se correlacionam com tempos de desempenho de consulta ruim. O comprimento da fila de disco para as outras duas unidades [system + page + tempdb] e [log + backups] nunca excede 3.

(*) Tentamos obter o profiler para capturar eventos relacionados à captura de bloqueio, mas o rastreamento incha para proporções ilegíveis e, pior, o aplicativo da web fica paralisado.

Não sendo DBAs, estamos ficando sem ideias rapidamente. Alguém pode pensar em algo que eu deva considerar olhar para o próximo ou qualquer coisa que eu tenha estupidamente perdido?

    
por JMusgrove 06.07.2009 / 23:46

5 respostas

1

À medida que você está executando o SQL 2005, é possível obter os dados do SQL Profiler e compará-los com os dados do Perfmon para ver se é possível ver uma correlação. Isso é feito salvando seus dados de rastreio e executando dados em arquivos usando as técnicas normais. Em seguida, abra o rastreio do SQL Profiler no profiler e, em seguida, uma das opções no menu de arquivo será importar dados de desempenho. Isso permitirá que você selecione uma consulta e veja o que os contadores estavam fazendo naquele momento (ou próximo a ela, dependendo do intervalo de coleta do perfmon).

Os picos de fila de disco nunca são bons. Especialmente tão alto. Qual é o IO que você está enviando para o disco quando a fila fica tão alta? Basicamente você não quer uma fila de disco maior que (2 * n) onde n no número de discos na matriz. Desde que você está usando um 2 disco RAID 1 n = 1 no seu caso (desde que você só tem a velocidade de um único disco).

No perfmon há um contador que é o segundo por leitura e segundos por gravação. Como são esses contadores quando as consultas começam a levar muito tempo para serem executadas. O que acontece normalmente? (Qualquer coisa acima de .02 segundos é ruim.) Qual é a expectativa de vida estimada da página? (Qualquer coisa abaixo de 300 segundos geralmente é ruim, mas isso pode variar.) Qual é a taxa de acertos do cache do SQL Server? (Qualquer coisa abaixo de ~ 97% geralmente é ruim. Eu gosto do meu acima de 99,9%.)

    
por 07.07.2009 / 08:23
1

Poucas coisas podem ser inúteis ou úteis; Se isso está acontecendo com procedimentos armazenados, pode ser o parâmetro sniffing - > link
Você está usando ASP para o aplicativo da web? Tivemos um problema semelhante, mas relacionado ao ASP + IIS e ao SQL usando procedimentos armazenados. Parece que me lembro de ser timeouts de semáforo que causariam isso. Levaria quase 30 segundos para executar uma consulta, mas tudo estava bem por um tempo. Eu não consigo encontrar minhas informações sobre isso, mas parece que me lembro de estar relacionado a tempos limite do IIS, isso foi no lado do IIS.

Esta ferramenta também pode ser útil - > link

    
por 07.07.2009 / 00:02
0

Você está vendo bancos de dados e / ou eventos de crescimento de log ? Tais eventos apareceriam no ERRORLOG e nos contadores de desempenho.

    
por 07.07.2009 / 01:00
0

Um par de coisas para tentar, o mais útil é o Plano de Execução Estimada de Exibição e o Plano de Execução de Inclusão Real no SMSS.

Se você marcar o botão Incluir plano de execução real antes de executar a consulta, após a execução da consulta, ele mostrará onde estavam os custos da consulta. Com base nos custos, geralmente é bem fácil descobrir onde deu errado. Se é um SORT, então é um índice ruim. Se estiver construindo uma tabela de hash, então é um índice ruim / junção ruim, há todos os tipos de coisas que podem dar errado e que você nem sabe acontecer durante uma simples consulta SELECT *.

A segunda coisa a tentar é executar o SQL Query Profiler (realce a consulta, clique com o botão direito do mouse em Rastreio de Consulta no SQL Profiler). Também encontrará ineficiências que podem ser eliminadas.

No entanto, suas consultas são muito simples e não estão apontando para falhas de design do banco de dados, mas podem pelo menos dar uma idéia de onde ir (obviamente, você irá inspecioná-lo em um momento em que a execução demorar mais tempo do que o esperado).

Outro lugar para procurar, e isso pode ser sobrecarga de informações, às vezes, é o SQL Server Profiler (que você menciona que você já usou, mas você pegou durante a execução 26s?). Você pode assistir tudo o que o SQL Server faz em (quase) em tempo real. Dependendo de quanto tempo a sua janela desse tipo de atividade é, se você estiver em prontidão para executar um rastreamento, assim que ele começar a ficar chocante, ative o rastreio, veja se há algo no servidor SQL que está aguardando.

    
por 07.07.2009 / 01:52
0

Você está reconstruindo manualmente as estatísticas das tabelas de seus bancos de dados regularmente? Se estiverem desatualizados e a opção de atualização automática das estatísticas estiver definida, as consultas poderão ser pausadas enquanto as estatísticas são reconstruídas.

Além de atualizar manualmente suas estatísticas, você também pode considerar a possibilidade de ativar estatísticas assíncronas.

Aqui está o T-SQL:

ALTER DATABASE dbName SET AUTO_UPDATE_STATISTICS_ASYNC ON

Leitura adicional:

link

Não estou convencido de que esta seja a causa raiz do seu problema - mas pode valer a pena descartá-lo.

    
por 07.07.2009 / 13:08