ASP.NET 응용 프로그램에서 SQLServer 연결 누출을 감지하는 방법은 무엇입니까?

https://stackoverflow.com/questions/212596

03-07-2019
|

문제

현재 ASP.NET 2.0 응용 프로그램에서 GUI 테스트를하고 있습니다. RDBMS는 SQL Server 2005입니다. 호스트는 Win Server 2003 / IIS 6.0입니다.

응용 프로그램의 소스 코드는 코드를 공개하지 않는 외부 회사에서 프로그래밍되었으므로 응용 프로그램의 소스 코드가 없습니다.

IIS를 다시 시작할 때 응용 프로그램이 잘 수행되지만 약간의 테스트 후 브라우저를 열고 닫은 후에는 응용 프로그램이 느려지고 느리게 시작됩니다. 이 동작이 프로그래머의 잘못된 폐쇄 연결 관행으로 인한 것인지 궁금했습니다. 여기 데이터베이스에서 열린 연결 누출이 의심됩니다.

.NET 쓰레기 수집가가 결국 닫을 것이라고 생각하지만 ... 시간이 걸릴 수 있습니까?

SQL Server Management Studio가 있으며 Activity Monitor에서 데이터베이스에 몇 가지 연결이 열려 있음을 알 수 있습니다.

위에서 언급 한 모든 것들로부터 주요 질문과 관련된 몇 가지 질문이 있습니다.

Connection Pool에서 사용하기를 기다리거나 응용 프로그램이 사용하기 때문에 열려있는 경우 연결이 열려있는 경우 SQL Server 2005에서 알 수있는 방법이 있습니까?
Somone은 이러한 종류의 문제를 추적하는 데 도움이되는 성능 카운터 나 다른 종류의 도구를 사용하는 방법을 배울 수있는 좋은 온라인/종이 자원을 알고 있습니까?
성능 카운터가 최상의 솔루션 인 경우, 내가 시청 해야하는 변수는 무엇입니까?

해결책

Web.config에서 항상 연결 문자열을 확인할 수 있습니다 (주로 연결 풀이 활성화 된 경우 연결 제한이 활성화 된 경우).

또한 IIS 6을 사용하는 경우 웹 애플리케이션을 설정하여 별도의 응용 프로그램 풀을 사용하도록 설정하고 메모리 및 프로세스의 재활용을위한 기타 옵션을 설정할 수 있습니다.

성능 카운터에 대해 쓰레기 수집기가 실행중인 시간, 응용 프로그램이 사용중인 메모리 금액 등을 확인할 수 있습니다.

SQL Server에 액세스 할 수있는 경우 응용 프로그램에서 만든 연결을 모니터링 할 수 있습니다 (설치된 모든 SQL Server 인스턴스에 대해 정의 된 성능 카운터가 있습니다).

몇 가지 기사가있었습니다 MSDN 매거진. 또한 SOS 디버깅 라이브러리를 사용하여 응용 프로그램 프로세스에 첨부하고 수동으로 확인할 수 있습니다.

그리고 소스 코드가없는 경우 사용하십시오. 반사기 응용 프로그램 소스를 얻으려면 (디버깅에 매우 유용 할 것입니다)

@later edit : 이것을 확인할 수 있습니다 의문 여기 stackoverflow.com도 있습니다

다른 팁

이 스레드가 비슷한 문제를 연구하는 것을 발견했습니다. SQL Server에서 Leaky Connections를 디버깅하는 좋은 방법으로 다음 SQL을 생각해 냈습니다.

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

이것이 당신에게 제공하는 것은 특정 데이터베이스 및 로그인의 모든 열린 연결입니다. 해당 연결에서 실행 된 마지막 SQL과 함께, 해당 SQL이 실행 된 시간에 따라 정렬됩니다.

연결 풀링으로 인해 연결 풀링이 코드에서 올바르게 닫히더라도 연결을 유지하기 때문에 연결 누출이 있다고 말하기 위해 많은 연결이 매달려 있다는 사실에 의존 할 수는 없습니다. 그러나 연결 누출이있는 경우 일부 연결이 "Frozen"이된다는 것입니다. 위의 쿼리에 표시되며 "Last_batch"타임 스탬프는 결코 변경되지 않습니다. 다른 연결도 주위에 매달려 있지만 새 SQL이 실행될 때마다 "Last_batch"타임 스탬프가 업데이트됩니다. 따라서 효과는 동결 된 연결 이이 쿼리의 맨 위로 떠 다니는 것입니다.

해당 응용 프로그램의 소스 코드가있는 경우, 이것이 고아 연결에서 실행 된 마지막 SQL을 제공한다는 사실은 디버깅에 매우 가치가 있습니다.

이 문제에 직면하여 SQL Server Profiler가 훌륭한 도구 인 것으로 나타 났으며 짧은 테스트 실행에서 사이트를 모니터링하고 연결 풀에서 재사용되지 않은 많은 연결 (SP_WHO)이 생성되는 것을 발견했습니다. 그런 다음 코드로 만든 SP에 대한 모든 호출에 "SP_RESET_CONNECTION"호출이 있는지 확인하십시오. 새 배치가 시작되기 전에 호출이 없으면 첫 번째 연결이 부족합니다.

MSDN 참조 (ado.net 성능 카운터)는 응용 프로그램을 프로파일 링 할 때 찾을 수있는 것에 대해 분명합니다. 당신은 그것을 사용하여 카운터를 모니터링 할 수 있습니다 Perfmon Windows에 내장 된 응용 프로그램.

그 외에는 ado.net 연결 풀링에 대해 배우는 것이 좋습니다. 코드의 버그를 정말로 의심하면 레드 게이트의 반사기 MSIL을 C#으로 분해하는 (지금은 무료).

연결을보고 활동 시간을 살펴보고 연결을 열어 두는 항목을 찾을 수 있는지 확인합니다.

솔루션이 IIS를 다시 시작하는 경우 응용 프로그램의 메모리 사용량을 살펴보고 메모리 누출이 있는지 또는 발자국이 성장하는 것이 있는지 확인할 수도 있다고 생각합니다.

열린 연결이 문제 인 경우 활동 모니터에서는 활동이없는 매우 많은 연결이 나타납니다.

성능 카운터의 경우 "SQL Server : General Stats"성능 객체를 살펴볼 수 있습니다.

Todd Denlinger는 환상적인 수업을 썼습니다 http://www.codeproject.com/kb/database/connectionmonitor.aspx SQL Server 연결 및 일정 기간 내에 제대로 폐기되지 않은 것에 대한 보고서를 시청합니다. 사이트에 연결하면 누출이있을 때 알려줍니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow