2009-12-15 4 views
4

이 내용을 이해할 수 없습니다. SQL Server에서 초당 수십 번 실행되는 프로세스가 있습니다 (데이터가 서버로 전송 됨). 프로세스가 잘 실행되며 처리 요청은 50 ~ 200ms가 소요됩니다. 그런 다음 약 1.5 분에 한번씩 모든 요청이 갑자기 15000ms에서 22000ms (15에서 22 초)가 소요됩니다 (그러나 산발적으로). 동시에 서버의 CPU 사용량이 급격히 감소합니다. 때로는 (약 70 %) 평균 디스크 대기열 길이는 CPU가 떨어지기 전과 요청이 느려지 기 전에 나타납니다.SQL Server가 20 초 동안 처리를 중지합니다.

perfmon에서 CPU를보고 있는데 보통 평균 CPU가 약 50 % 인 20 %에서 70 % 사이에서 점프합니다. 일이 멈 추면 약 20 초 동안 약 20 %의 스파이크로 0 %로 떨어집니다.

동시에 SQL 활동 모니터를보고 있습니다. 일반적으로 1 ~ 4 개의 EXECUTE 트랜잭션이 나열되지만 EXECUTE 트랜잭션이 시작되면 20 개 또는 30 개의 트랜잭션으로 시작됩니다. 트랜잭션이 들어오고 있지만 처리 중이 아닙니다.

내가 블록 확인하고 볼 수 없을 : 나는 "스냅 숏 격리"

에서 실행하고

Select A.* 
     From master.dbo.sysprocesses as A with (nolock) 
     Where A.blocked <> 0 

참고 I 오류 로그에 시스템 기록 교착 상태를 가지고, 아무도보고되지.

실행중인 다른 프로세스에 대해 SQL 에이전트를 점검했지만 이러한 이벤트가 발생할 때 스케줄되지 않았습니다.

다른 이벤트가 들어오는 SQL 프로파일 러를 보았는데 아무 것도 없었습니다. 또한 File Growth 이벤트를 지켜 봤는데 아무 것도보고하지 않습니다.

요청이 20000ms를 차지하는 경우에도 SQL 프로필러는 2000 미만의 CPU 및 50 미만의 CPU를보고합니다. 프로세스 자체는 리소스를 사용하지 않는 것으로 보입니다. 그러나 로그 아웃 이벤트는 높은 읽기와 CPU를보고합니다 (모든 관련이 있는지는 잘 모르겠습니다).

이 이벤트가 발생했을 때 내 이벤트 로그에는 아무 것도 없습니다.

아이디어가 있으십니까? 봐야 할 다른 곳?

Window 2003 32 비트에서 SQL Server 2005 Standard를 실행 중입니다.

+0

마이클, 내 블로그 게시물보기 [설명되지 않는 SQL Server 시간 초과 및 일시적인 차단] (http://blog.digitaltools.com/post/2009/02/24/Unexplained-SQL-Server-Timeouts-and-Intermittent-Blocking .aspx). 특히 저장된 proc에 "SELECT INTO"가 있거나 임시 테이블에서 삭제 된 경우. Jim – JBrooks

+0

일반적으로 우리는 데이터가 삽입되기 전에 정의 된 테이블 변수 (임시 테이블이 아님)를 사용합니다. 나는 모든 과정을 살펴보고 다시 확인한다. –

답변

1

문제는 자동 체크 포인트입니다. SQL 서버가 자동 체크 포인트를 실행하면 다른 트랜잭션이 지연됩니다. 이는 아마도 체크 포인트와 관련된 디스크 I/O와 관련이 있습니다. 을 waittype WRITELOG을 보여주는

dm_exec_requests (있는 waittime 0) 요청이 트랜잭션을 커밋하고 (디스크에 기록) --Remus Rusanu

이를 확인하려면 경화되는 로그를 기다리는 의미, 나는 켜져 체크 포인트 로깅을 수행하고 여러 사건 중 perfmon 세션을 기록했습니다. 그런 다음 로그를 perfmon과 비교하여 문제가 항상 내 데이터베이스 중 하나의 체크 포인트와 관련되어 있음을 확인했습니다.

DBCC TRACEON (3502, -1) 검사 기록

DBCC TRACEOFF에 --turn (3502, -1) 로그

에게 --read xp_readerrorlog

EXEC 검사 기록을 --turn

[데이터베이스 이름]으로 SELECT DB_Name ([dbid]) - 로그에 언급 된 데이터베이스 ID 확인

특정 데이터베이스에는 많은 삽입 및 삭제를 생성하는 프로세스가 있습니다. 해결책은 기록중인 데이터의 양을 줄이기 위해 해당 프로세스를 다시 쓰는 것입니다. 또 다른 옵션은 하드웨어를 추가하는 것입니다.

기여한 모든 사람에게 감사드립니다.

0

전체 텍스트 검색을 사용하고 있습니까?

나는 때때로 인덱스가 재구성 될 것이라고 생각하고 있습니다.

아마도 인덱스 전체를 자동화하거나 비 클러스터형 인덱스로 변경해보십시오.

+0

감사합니다. 그러나 전 텍스트 검색을 사용하지 않습니다. –

0

아마도 초당 읽기 및 쓰기와 같이 perfmon에 몇 가지 카운터를 더 추가 할 것입니다. 여기에서 I/O 문제인지 확인할 수 있습니다. 또한 MSDN entry on SQL performance을 확인하십시오. 그것은 적어도 나에게 체크 아웃하는 것에 대한 좋은 아이디어를 정말로 주었다.

+0

나는 나쁜 모양에 있다고 생각한다. % 디스크 평균 633 (설명 할 수 없음). 평균 디스크 초/읽기.042 평균 디스크 초/쓰기 .052 디스크 읽기/초 2.041 디스크 쓰기/초 71 이것은 패리티 RAID이지만이 숫자는 야구장 밖에 있다고 생각합니다. 동의하니? –

+0

디스크 레벨이 얼마나되는지 알지 못하면 디스크 IO가 문제가되는지 말할 수 없습니다. IOPS를 계산할 때 사용할 수 있도록 4 개의 디스크가있는 RAID 5 어레이가 있습니다. reads + (4 * Writes))/디스크 수 = 총 IO/초입니다. 숫자가 구멍이 뚫린 전형적인로드에서는 (724.364 + (4 * 5.707))/4 = 186.798입니다. 나는 글쓰기보다 더 많은 글을 읽었지 만, 글을 많이 쓴 것처럼 보이지만, 끔찍한 것은 아니다. 나는 코드에 시간을 소비하기 전에 그것을 점검 할 것이다. –

+0

하지만 다시 말하자면 일반적으로 하드웨어보다는 먼저 코딩하는 것보다 서버 측에서 더 낫다. –

2

오류가 드라이브를 확인 했습니까? 어쩌면 뭔가 진행되고있는 것 같습니다. RAID 어레이 인 경우 어레이의 상태를 점검하십시오.

+0

할 것입니다 (ISM을 기재 할 것입니다). 감사. –

0

장시간 실행되는 요청 (주기적으로 샘플링)에 대한 sys.dm_exec_requests의 wait_type, wait_resource 및 wait_time은 무엇입니까? 이 요청으로 하위 작업 (sys.dm_os_tasks)이 생성됩니까? 그 일은 무엇입니까?

+0

일반적으로 시스템 프로세스처럼 보이지 않는 프로세스의 경우 waittype은 null이고 대기 시간은 0입니다. 사건 중 하나에서 dm_exec_requests를 쿼리하여 OLEDB (대기 시간 15) 및 대기열 유형 WRITELOG (대기 시간 0) 중 하나의 트랜잭션을 확인했습니다. 나는 이것이 무엇을 의미하는지 연구해야 할 것이다. dm_os_tasks에서 찾을 내용을 잘 모름 –

+1

WRITELOG는 요청이 트랜잭션을 커밋했고 로그가 강화 (디스크에 기록) 될 때까지 대기 중임을 나타냅니다. OLEDB는 분산 쿼리 대기입니다. sys.dm_os_tasks에서 task_state를 찾아야합니다. 보류는 스케줄러 병목 현상을 나타냅니다 (모든 작업자가 점유 중임) –

+0

정보를 제공해 주셔서 감사합니다. 사건이 끝나면 CPU가 다시 실행될 때를 씁니다 (통계 분석이 아닌, 눈을 뜨고 있지만) dm_os_tasks는 세 가지 보류 작업을보고합니다. 나는 조금 연구 할 것이다. 한편, 로그가 '강화 될 때'를 알 수있는 방법은 무엇입니까? –

0

메모리 사용량을 확인 했습니까? Windows Server 2003 R2는 기본적으로 집중적 인 부하가 발생하는 경우 모든 메모리 할당을 기본적으로 다시 시작합니다. 이 경우 SQL Server는 최소한의 메모리 (4MB 정도)로 강제 실행 된 다음 비교적 정상적인 수준으로 돌아갈 때까지 천천히 서버에 메모리를 다시 할당합니다. 대용량 파일이 SAN을 통해 복사 될 때 이러한 상황이 발생하는 것을 확인했습니다. 트랜잭션 로그가 매우 크고 서버의 사용량이 지나치게 많은 경우 트랜잭션 로그 백업 프로세스에 의해 트리거 될 수 있다고 들었습니다.

+0

작업 관리자를보고 (가장 좋은 방법인지 잘 모르겠 음) Sqlservr.exe 프로세스에서 약 2,544,000 개의 mem 사용량을보고합니다. 그것은 조금 변동하지만 결코 (사건을 통해서조차도) 크게 떨어지지 않습니다. –

0

지연이 CPU 시간을 증가시키지 않으므로 속도가 느리지 않습니다. 서버가 성공하지 못하는 차단 호출을하고있는 것처럼 들리면 결국 시간이 초과됩니다. 당신은 교착 상태를 배제했습니다. 하드 드라이브 문제 일 경우 이벤트 로그에 무엇인가를 볼 것으로 예상됩니다.

Wireshark과 같은 네트워크 스니퍼를 설치하여 일시 중지가 시작될 때 흥미로운 점이 있는지 확인하십시오.

0

하나의 옵션 : 통계 업데이트. 당신이 충분히 자주 글을 쓰고 있다면, 당신은 재 계산 임계 값에 도달 할 것입니다. 이 문서 "Index Statistics on MSDN"하고 옵션 90 초마다 비록 "AUTO_UPDATE_STATISTICS_ASYNC"

에서

봐 조금 많이 ...

관련 문제