Tempos limite de configuração: SQL Server 2008 / IIS 7.5

Question

Recentemente, migramos de um sistema Win 2003 / SQL Server 2000 para o Win 2008 de 64 bits R2, SQL Server 2008 R2.

Nossos sites estão no asp clássico, e isso não pode ser alterado para outra linguagem de script no momento.

No servidor antigo, se eu ficasse preso em algum tipo de loop infinito, a página lançaria um erro.

No novo servidor, eu tenho uma página que tem algum tipo de problema de loop, embora o SQL SP seja chamado apenas uma vez (e executa bem como uma consulta no servidor) atrela o servidor SQL e, portanto, bloqueia tudo dos nossos sites.

Vou pegar meu código, não é nada demais. Mas preciso garantir que o servidor atinja o tempo limite quando isso acontecer. (A página em que estou trabalhando funciona bem com certas instâncias da consulta e bloqueia com outras pessoas usando uma variável de consulta diferente. Não posso fazer com que algo parecido me surpreenda em uma página que não toquei por três anos .)

Não consigo descobrir como um SP que é executado uma vez no servidor, de uma página ASP, está conectando o SQL Server dessa maneira. É obviamente algum tipo de problema de tempo limite, mas não consigo descobrir onde / quais valores de tempo limite devem ser alterados.

Eu realmente tenho que fazer o desktop remoto para o servidor e matar o processo no servidor SQL.

Eu tenho medo de ser generalista, e gerenciamento de servidor não é minha coisa, mesmo que seja minha responsabilidade, então eu tenho quase certeza de ter dúvidas sobre qualquer resposta que eu receba.

Como posso rastrear isso? Quais configurações eu preciso mudar?

Mais informações: não é o SQL Server No nosso site de teste, criei um arquivo ASP que acabou de fazer um loop infinito (fazer enquanto 1 = 1) e tinha o mesmo problema - os outros sites não carregavam - sem que o SQL Server estivesse envolvido. Então, acho que a razão pela qual o processo estava pendente é que a página não estava no tempo limite como deveria e, portanto, a conexão com o SQL nunca foi fechada. Matar o processo no SQL Server redefiniria a página de alguma forma.

Para meu loop infinito intencional, tive que atualizar o pool de aplicativos para me livrar dele. Isso aponta mais para o IIS ou as configurações do ASP.

Os tempos limite do ASP são definidos como o padrão quando o servidor foi carregado pela primeira vez.

Ainda não consigo entender porque um arquivo está bloqueando todos os sites. Novamente, isso não aconteceu no servidor antigo.

    

Answer 1

Para o próximo cara.

A solução para esse problema se resume a percepções, quando alguém - como eu - não está realmente familiarizado com o gerenciamento de servidores.

Como afirmei na pergunta original, acabamos de mudar de um servidor antigo - Windows Server 2003 / SQL Server 2000 - para um novo, que usa o Windows Server 2008 R2 de 64 bits e o SQL Server 2008 R2. Não configurei o servidor original e paguei a alguém para migrar as coisas para o novo servidor, dando-lhe as instruções: "Basta configurá-lo da maneira que o servidor antigo foi configurado". Heh.

O servidor antigo tinha 9 anos, uma máquina com processador dual Xeon com 1 GB de RAM . O servidor original foi configurado com dois sites - nosso sistema de reservas e o site da empresa - ambos usando o mesmo pool de aplicativos. Como os sites foram adicionados ao longo dos anos, eles foram adicionados ao pool de aplicativos padrão. Com nossos problemas de recursos, isso foi o melhor que pudemos fazer. E em algum momento, alguém deve ter definido o tempo limite para ser um valor muito curto, provavelmente porque o servidor ficou um pouco entupido às vezes.

O novo servidor tem 32GB de RAM e um processador de 4 núcleos. Mas o consultor que contratei fez exatamente o que eu pedi - quase - e configurou tudo como estava no servidor antigo, incluindo colocar todos os sites no mesmo pool de aplicativos. A única coisa que ele não fez, aparentemente, foi definir o tempo limite para o valor mais curto que era o servidor antigo deve ter sido definido para.

No novo servidor, quando carreguei uma página ASP que chamava um procedimento armazenado, o SQL Server usou todo o processador alocado a ele e ficou pendurado lá e todos os sites ficaram paralisados, até que eu o interrompi no SQL Server. Depois de um pouco de pesquisa, descobri que a mesma coisa aconteceu - todos os sites pararam - ao executar qualquer tipo de loop infinito, mesmo que o SQL Server não estivesse envolvido, e que a reciclagem do pool de aplicativos "consertaria" isso.

Tudo se resume a suposições / percepções: o tempo limite no servidor antigo era curto o suficiente, que ao depurar algo, eu nunca percebi que todos os sites estavam bloqueados , porque era apenas para 15 ou 20 segundos, a página terminaria, eu consertaria e continuaria. Quando o tempo limite é definido para 120 segundos, no entanto, esse é um jogo totalmente diferente. Como o SQL Server estava parado, achei que era um problema do SQL Server, mas estava pendente porque o registro e a conexão não estavam fechados porque a página estava presa em um loop ... então, apenas apareceu que o SQL Server fazia parte do problema.

A solução final era separar a maioria dos sites em seus próprios pools de aplicativos (duh) e ajustar os valores de tempo limite para ASP de acordo com o que era apropriado para cada site.

    

Answer 2

Primeiro, e me escute, é o que eu sempre digo aos desenvolvedores que reclamam de declarações ou procedimentos de longa duração e querem mexer com os tempos limite de consulta:

A melhor coisa a fazer é corrigir seu código.

Descobrir qual código está sendo executado por muito tempo (use o SQL Profiler, observe os planos de consulta ou apenas observe seu código até que você o crie) e repare o problema. Pode ser código, indexação, estatísticas desatualizadas, bloqueio de outra coisa, armazenamento lento ou um monte de outras coisas.

Ok, pronto.

Se você quiser alterar o tempo limite da consulta para que as coisas funcionem enquanto você descobre o que está quebrado, procure em seu código para localizar onde você cria objetos de consulta ADO (conjuntos de resultados, objetos de comando etc.) e altere as propriedades .QueryTimeout e / ou .CommandTimeout.

IIRC, o padrão para essas propriedades é de 60 segundos. Faça "tempo suficiente". AFAIK, não há uma maneira global para definir .QueryTimeout e / ou .CommandTimeout em um IIS ou global de aplicação, mas eu não sou um cara do IIS / ASP, eu sou um DBA.

Observe que aumentar esse valor pode significar que o código de execução mais longa estará bloqueando outros usuários por mais tempo e poderá levar a danos colaterais. O valor padrão é definido como um valor que pode parecer baixo para impedir que sua conexão atrapalhe outras conexões.

Não existe uma maneira simples de eliminar as consultas que são executadas "muito longas" no SQL 2008.

O material "timeout da consulta" que você vê nas caixas de diálogo "Propriedades" do SQL Server tem a ver com tempos limite para servidores vinculados. IOW, que controla o valor de tempo limite para o servidor local quando ele atua como um cliente e se conecta a um servidor remoto em seu nome. (Na prática, é como alterar os valores de QueryTimeout em seus objetos de consulta, mas está tudo dentro do SQL Server.) Isso não ajudará você.

O antigo "governador de consultas", quando configurado, estimará quanto tempo uma consulta levará e sempre errará sempre que eu tentar usá-la. Todos que eu vi falar sobre isso descobriram que é decepcionante. O "governador de recursos", que você pode notar, é projetado para limitar o uso de RAM e CPU, não o tempo. Portanto, você não quer nada disso.

Você poderia escrever algo que pudesse matar as consultas. MAS:

• Você pode pisar no importante trabalho das pessoas. (Incluindo backups, re-indexação, etc.)
• Aquelas consultas mortas será revertida. Rolling back leva uma quantidade finita de tempo e o trabalho pode desaparecer.
• A reenvio dessas consultas revertidas pode causar ainda mais carga em seu servidor.

Em suma, esse tipo de projeto é geralmente mais difícil de acertar do que consertar o código de longa duração, em primeiro lugar.