sp_reset_connection을 실행하는 데 오랜 시간이 걸리는 원인은 무엇입니까?

sp_reset_connectionSQL Server 프로파일 러를 통해 볼 때 시스템 저장 프로 시저를 실행하는 데 몇 밀리 초 이상 걸리는 이유는 무엇 입니까?

SQL Server 프로파일 러를 사용하여 프로덕션 시스템에서 간단한 추적을 수행 한 다음 SqlNexus를 사용하여 분석했습니다. SqlNexus는 sp_reset_connection의 누적 지속 시간이 전체 추적의 33 %로 가장 높다는 것을 나타냅니다. 관찰 된 지속 시간은 0-7 초 (12-6,833,270 마이크로 초)이지만 평균 0.956 초입니다.

풀링 된 연결이 재사용 될 때 sp_reset_connection이 호출되고 있음을 이해합니다. 나는 이것이 외래의 흔적 으로 인해 발생할 수 있다는 제안을 보았지만 실제로는 그렇지 않습니다.

Sproc이 호출 될 때 서버가 수행하는 작업 을 읽었 지만이 경우 문제가 될 것이라고 생각하지 않습니다. 코드가 열려있는 트랜잭션이나 정리 해야하는 거대한 임시 테이블을 남기지 않습니다.

또한 /server/199974/sp-reset-connection-taking-a-long-time-to-run을 보았지만 도움이되지 않았습니다.

편집 (2013-12-23) : 모든 경우에 읽기 및 쓰기는 0이고 CPU는 거의 항상 0입니다 (16ms에서 0이 아닌 CPU의 두 인스턴스 만).

sql-server sql-server-2008

— 전체적 개발자
소스

해당 이벤트에서 읽고 쓰는 데 어떤 종류의 값이 표시됩니까?

— Martin Smith

실행하는 쿼리 종류에 대한 자세한 정보를 제공 할 수 있습니까? 길거나 복잡한 트랜잭션, XML 처리, 임시 테이블과 같은 특히 흥미로운 세부 정보

— Edward Dortland

@Martin 읽기 및 쓰기는 0입니다. 질문을 업데이트했습니다. (주말 동안 데이터에 액세스 할 수 없었습니다.)

— 전체적 개발자

@EdwardDortland 대부분의 쿼리는 명시 적 트랜잭션이나 임시 테이블을 사용하지 않고 상당히 간단한 선택 및 업데이트입니다. 실제로 이러한 연결에서 실제로 실행되는 실제 쿼리는 매우 빠르며 몇 ms에 불과합니다.

— 전체적 개발자

@HolisticDeveloper-공개 트랜잭션을 남겨두고 실험을 수행했으며 0이 아닌 읽기 및 쓰기를 볼 수 있으므로 그때는 그렇지 않다는 데 동의합니다. 이 상황이 다소 영구적입니까? 내가 확장 이벤트 추적 캡처를 실행하는 것 그렇다면 RPC:Starting, RPC:Completed짧은 기간이 다음 SPID가 해당 시간 동안 발생한 유형을 기다릴를 알기 위해 데이터를 통해보고에 대한 유형을 기다립니다.

— Martin Smith

답변:

마지막으로 더 자세한 답변을 작성할 시간이있었습니다.

일반적으로 간단한 절차 sp_reset_connection를 실행하는 데 시간이 오래 걸리는 세 가지 주요 이유 가 있습니다.

CPU 리소스를 기다리고 있습니다
어딘가에서 잠금이 차단되었습니다 (아마 DML 또는 경쟁 거래의 결과)
네트워크 속도가 느리고 결과를 클라이언트에 반환하는 데 시간이 오래 걸립니다

Ad 1) CPU 리소스를 기다리는 경우 신호 대기로 표시됩니다. 이것이 문제인지 진단하는 방법에 대한 귀하의 질문에 대한 나의 의견을 참조하십시오

광고 2) 잠금을 기다리는 경우 두 개의 스냅 샷을 비교하여 가장 잘 진단됩니다 sys.dm_os_wait_stats. 이를 수행하는 방법에 대한이 기사를 참조하십시오.

http://www.sqlsoldier.com/wp/sqlserver/sqludbaweekbeanefficientdba

LCK_ [Something]을 오래 기다린 경우 sys.dm_tran_locks어떤 개체가 잠겨 있는지 추적하도록 쿼리하십시오 . 귀하의 경우에는 일종의 SCH- [Something]> 잠금이 귀하를 차단하는 것으로 예상됩니다.

광고 3) 2 단계에서 먼저 OLEDB 및 ASYNC_NETWORK_IO를 찾기 위해 네트워크 문제를 진단하는 가장 쉬운 방법은 2 단계에서 대기합니다 (네트워크를 오랫동안 기다리는 경우 그 중 하나가 표시됨). 대기 시간이 xperf -on latency길면 netmon 또는 wireshark와 같은 네트워크 모니터링 프로그램을 사용 하여 대기 시간을 확인하십시오. 네트워크 속도가 느리면 호출중인 응용 프로그램 서버가 연결을 재활용하는 데 충분히 빠르게 응답하지 않아 발생할 수도 있습니다.

— 토마스 케서
소스

아직 문제가 재발하지 않았으므로이 시점에서 추가 답변을 위해 제공된 답변을 사용할 수 없습니다. 그러나 SQL Server 성능 전문가라는 평판을 바탕으로 답변을 받고 있습니다.

— 전체적 개발자

난 그냥 버그에 대한 기술 자료 문서를 건너 왔어요 수 있습니다 이 문제와 관련 될 수있다. 에서 FIX : 성능 문제는 SQL Server의 데이터베이스 잠금 활동이 증가 할 때 발생 (KB 2926217), 증상 중 하나가이 기술 sp_reset_connection을 완료하는 데 시간이 오래 걸릴 수 있습니다. 핫픽스는 다음 업데이트에 포함되어 있습니다.

SQL Server 2008 SP3 누적 업데이트 17
SQL Server 2008 R2 SP2 누적 업데이트 13
SQL Server 2012 SP1 누적 업데이트 9
SQL Server 2014 누적 업데이트 1

이 동작을 관찰 한 서버에서 누적 업데이트 5가 포함 된 SQL Server 2008 SP3이 실행 중이므로이 버그가 발생했을 수 있습니다. 아직 누적 업데이트를 시도하지 않았으므로 (문제가 항상 되풀이되지는 않음) 문제가 해결되는지 확인할 수 없습니다. 그러나 누군가 동일한 증상을 보인 경우에 정보를 제공하고 싶었습니다.

— 전체적 개발자
소스