Como detectar vazamentos de conexão SqlServer em um aplicações ASP.NET?

Question

Atualmente estou fazendo alguns GUI testes em um aplicativo ASP.net 2.0. O RDBMS é SQL Server 2005. O anfitrião é Win Server 2003 / IIS 6.0.

Eu não tenho o código fonte da aplicação, porque ele foi programado por uma empresa externa que não está liberando o código.

Tenho notado que os aplicativo executa bem quando eu reiniciar o IIS, mas depois de alguns testes, depois de ter aberto e fechado meu navegador por um par de horas, o aplicativo começa a ficar mais lento e mais lento. Eu queria saber se este comportamento deveu-se a uma prática conexão fechamento ruim dos programadores:. Estou suspeitando um vazamento de conexão aberta no banco de dados aqui

Eu acho que o coletor de lixo .Net acabará perto deles, mas ... que pode demorar um pouco, não?

Eu tenho SQL Server Management Studio e eu faço notificação do monitor de atividade que existem algumas conexões bastante aberto no banco de dados.

De tudo o que está sendo dito acima, aqui estão algumas perguntas relacionadas à questão principal:

1. Existe alguma maneira de saber em SQL Server 2005 se as conexões estão abrir porque eles estão à espera de ser usado em um pool de conexão ou se eles estão abertos, porque eles são usados ??por um aplicação?

2. O somone sabe de bom recursos online / papel onde eu poderia aprender a usar desempenho contadores ou algum outro tipo de ferramentas para ajudar a rastrear este tipo de questões?

3. Se os contadores de desempenho são a melhor solução, quais são as variáveis ??que eu deve assistir?

Answer 1

Você pode sempre verificar as seqüências de conexão de web.config (principalmente se eles têm o pool de conexão ativado, se eles têm alguma limites de conexão habilitado).

Além disso, se você estiver usando o IIS 6, você pode definir o seu aplicativo da Web para usar um pool de aplicativos separado, e definir outras opções para a reciclagem de memória e processos.

Sobre os contadores de desempenho, você pode verificar quanto tempo o coletor de lixo está em execução, quanta memória o aplicativo está usando, etc.

Se você tem acesso ao servidor SQL, você pode monitorar as conexões feitas a partir de sua aplicação (há contadores de desempenho definidos para cada instância instalada do SQL Server).

Houve alguns artigos em MSDN Magazine . Além disso, você pode usar a biblioteca SOS depuração para anexar ao processo do aplicativo e verificá-lo manualmente.

E, se você não tem o código-fonte, tente usar Refletor para obter as fontes do aplicativo (que seria muito útil para depuração)

@Later edit: Você pode verificar este questão aqui no stackoverflow.com demais

Answer 2

Encontrado esta discussão pesquisando um problema semelhante. Eu vim com o seguinte sql como uma boa maneira de conexões de depuração com vazamentos em SQL Server:

SELECT S.spid, login_time, last_batch, status, hostname, program_name, cmd,
(
      select text from sys.dm_exec_sql_text(S.sql_handle)
) as last_sql
FROM sys.sysprocesses S
where dbid > 0
and DB_NAME(dbid) = '<my_database_name>'
and loginname = '<my_application_login>'
order by last_batch asc

O que isso lhe dá é todas as conexões abertas em um banco de dados e login particular, juntamente com o último sql executado nessa conexão , classificado pelo tempo em que o SQL foi executado.

Por causa do pool de conexão, você não pode apenas contar com o fato de que há um grande número de conexões que penduram ao redor para lhe dizer que você tem um vazamento de conexão, porque o pool de conexão irá manter conexões ao redor, mesmo se eles estão fechados corretamente a partir código. No entanto, se você tem um vazamento de conexão, o que você vai ver é que algumas conexões tornam-se “congelado” -que vai aparecer na consulta acima eo timestamp “last_batch” nunca vai mudar. As outras conexões também vai pendurar ao redor, mas cada vez nova sql é executado sobre eles, o timestamp “last_batch” é atualizado. Assim, o efeito é que as conexões congelados irá flutuar para o topo desta consulta.

Se você tem o código-fonte do aplicativo em questão, o fato de que isso lhe dá a última sql executado na conexão órfão é muito valioso para a depuração.

Answer 3

Eu enfrentei este problema e encontrou SQL Server Profiler para ser uma grande ferramenta, que monitorou o site em um curto prazo de testes e muito notado de conexões sendo criado (sp_who) que não foram reutilizados por Connection Pool, então eu só abriu SQL server Profiler e, em seguida, verificar se todas as chamadas para SP feitas a partir do código foram seguidos por uma chamada "sp_reset_connection". Se a chamada não está lá antes do início de um novo lote que você está apenas falta a primeira conexão.

Answer 4

A referência MSDN sobre ( ADO.NET contadores de desempenho ) é bastante claro sobre o que você pode olhar para quando o perfil da aplicação. Você pode monitorar os contadores usando o perfmon aplicativo embutido no Windows.

Além disso, eu sugiro o aprendizado sobre o pool de conexão ADO.NET. Se você realmente suspeitar de um bug em seu código, você pode dar uma olhada no que faz usando refletor da Red Gate (gratuito para agora) que desmonta o MSIL em C #.

Answer 5

Gostaria de começar por olhar para as conexões e olhando para o tempo de atividade, e veja se você pode encontrar itens que estão mantendo as conexões abertas.

Eu diria que pensou que se a solução é reiniciar o IIS, você também pode olhar para o uso de memória do aplicativo para ver se há um vazamento de memória ou algo lá que realmente causa a sua pegada de crescer.

Se conexões abertas eram um problema, no monitor de atividade você veria um número muito grande de conexões sem atividade.

Para contadores de desempenho que você pode começar a olhar para o "SQL Server: Estatística Geral". Objeto de desempenho

Answer 6

Todd Denlinger escreveu uma classe fantástica http://www.codeproject.com/KB/ database / connectionmonitor.aspx que relógios conexões SQL Server e relatórios sobre os que não tenham sido devidamente transferidos dentro de um período de tempo. Fio-lo em seu site, e vai deixar você saber quando há um vazamento.