sql server 2005 사용 중입니다.
근래에 없던 데드락 이슈가 좀 있어서
SELECT TOP 10
[Wait type] = wait_type,
[Wait time (s)] = wait_time_ms / 1000,
[% waiting] = CONVERT(DECIMAL(12,2),
wait_time_ms * 100.0 / SUM(wait_time_ms) OVER())
FROM sys.dm_os_wait_stats
WHERE wait_type NOT LIKE '%SLEEP%'
ORDER BY wait_time_ms DESC;
쿼리를 이용하여
아래와 같은 대기 상태 모니터링 중에 결과가 나왔습니다.
Wait Type Wait Time(s) %Waiting
---------------------------- ------------- ---------
SQLTRACE_BUFFER_FLUSH 236261 78.51
WRITELOG 19113 6.35
PAGEIOLATCH_EX 18999 6.31
PAGEIOLATCH_SH 10927 3.63
CXPACKET 6720 2.23
OLEDB 3578 1.19
LATCH_EX 1681 0.56
ASYNC_IO_COMPLETION 555 0.18
BACKUPBUFFER 542 0.18
BACKUPIO 540 0.18
제일 상위에 SQLTRACE_BUFFER_FLUSH 부분이 몇군데 설명을 찾아보니
---------------------------------------------------------------------------------------------------
- 태스크가 백그라운드 작업이 4초마다 추적 버퍼를 디스크로 플러시 할 때까지 대기하는 경우에 발생.
- wait(%)은 DB서버의 부하가 클수록 그 비율은
감소한다는 내용이다.
바로 이점이 wait 분석에서 주의를 가져야 할 부분이라고 보는데 DB서버에 부하가 많은 상황에서 *.trace 파일에
로그를 기록하는 작업 또한 서버의 리소스를 소비하는 작업이므로 대기는 발생하기 마련이다.
하지만 다른 DB작업에 부하가 쏠리는 것은 당연하고 전체적인 비율은 작지만 그 대기시간
만큼은 trace 파일에 기록되는 양에 따라서 비례해서 증가할 것이라는 점이다.
---------------------------------------------------------------------------------------------------
라는 코멘트를 찾았는데 좀 이해가 가질 않아서 질문 올려봅니다.
현재 클라나 해당 서버에서는 추적을 하고 있지는 않는데요...
어찌해서 이 부분 수치가 제일 높은건지...
또 해제를 하려면 어떤 방법이 있는지
도움 부탁합니다.
감사합니다.
Comment 6
-
디비러
2013.10.07 14:28
-
minsouk
2013.10.07 16:27
변경 없는 디폴트 트레이스가 가장 많은 wait %를 차지하고 있다면, 해당 서버는 비교적 부하가 적은 서버일것 같습니다. 디폴트 트레이스는 비교적 작은 리소스를 사용함에도 불구하고 해당 서버에서 비율이 높게 나온것이 그 이유 입니다. 서버가 더 많은 일을 하게 된다면, 다른 리소스 사용량이 증가하게 되고, 그에비해 작은 리소스를 차지하는 SQLTRACE_BUFFER_FLUSH의 wait %는 자연적으로 낮아지게 될겁니다. wait 리소스 %를 분석할때 이런 부분을 주의깊게 봐야 합니다. 위 결과가 만약 서버 리소스를 매우 적게 사용하고 응답속도도 정상인 상황에서 단지 SQLTRACE_BUFFER_FLUSH wait % 가 높다고 해당 트레이스를 끈다면, default trace를 수행함으로 얻는 많은 이득을 포기하게 됩니다. 해당 서버에 buffer flush, log write, io latch 가 높은 것으로 봐서, 디스크의 응답속도인 avg. disk sec / transfer 나 read, write 를 살펴보아야 할 듯 합니다.
궁금한 것이 하나 있는데요, 해당 서버에 실제 응답속도에 문제가 있는 것인가요? 아니면 pro-active wait analysis(미리 wait 를 분석해보고 서버의 baseline을 조사하는 것)를 해보는 것인가요? 만약 후자의 경우라면 default trace 를 그대로 두심이 좋을듯 합니다.
-
디비러
2013.10.07 17:03
좋은 답변 대단히 감사합니다.(__)-- 후자의 경우라면 default trace 를 그대로 두심이 좋을듯 합니다.네 이부분은 계속 default trace 1값으로 두어야 할 듯 합니다.^^대기가 비약적으로 높게 나와서 좀 당황했는데 설명해주신 내용 보고선 한숨 돌렸습니다.지적해주신 부분들 중에하루종일 이것 저것 확인 해본 결과 대기 타입 중 WRITELOG 부분은배치 스크립트를 수정함으로 많은 감소가 있을 걸로 예상이 되네요.배치에서 트랜잭션이 while문 안에 있는 경우가 대다수네요....ㅜㅜ헌데...buffer flush, io latch 부분에서-- 디스크의 응답속도인 avg. disk sec / transfer 나 read, write 를 살펴보아야 할 듯 합니다.말씀해주신 부분은 확인 후에 대책은 어떤 방법이 있을까... 한번 더 여쭤 봅니다.사실 근래에 데드락이라든가... 타임아웃 에러 로그가 게임 서버쪽에서 자주 찍히고 있고그로 인해아이템 지급 이라든지 아이템 구매 부분에서 문제가 발생했었습니다.운영툴에서 아이템 지급을 했는데 몇 몇 유저에게만 여러번 지급이 된다든가...아이템 구매를 했는데 캐시는 차감이 됐는데 아이템이 안들어 온다든가 하는 문제가 있었고그 때마다 게임 서버 로그가 데드락 또는 타임아웃이 찍히더군요.물론 DB 단에서는 없는 실력이나마 제가 책임을 지고 있으니 어케든 심도있게 모니터링 해서문제점 발견 되면 해결해 나가겠지만...게임 서버쪽에선 무조건 DB문제다..라고 해버리니 아주 참 난감하네요 ^^어쨌든 이참에 해당 DB서버를 제대로 파악 및 튜닝을 하려고합니다.자주 질문 올릴 듯 하네요.많은 도움 부탁합니다.(__) -
minsouk
2013.10.07 20:17
데드락은 프로세스 처리 체인에 의해 어쩔수 없습니다 그러나 다양한 기법으로 완화 가능합니다 기본적으로 데드락 그래프를 추적해 전달주시면 99% 감소시킬수 있습니다. -
디비러
2013.10.08 10:21
네 오늘 하루는 데드락 추적 찐하게 할 계획입니다.
근데... 어디로 전달해드리면 될까요??
-
minsouk
2013.10.08 11:17
저 말고도 여기 실력있는 분들이 많이 있습니다. 여기 올리시면 분석이 금방 될듯 합니다.
내용을 공개하기 그렇다면 minsouk@hotmail.com 으로 주시고 문자 하나 주세요~ 01099670955 입니다.
아... 방금 sys.configurations 테이블 조회를 해보니...
show advanced options 는 값이 1이고....
default trace enabled 도 값이 1인 상태인데요...
default trace enabled를 0으로 설정해야 할까요??
지금현재도 SQLTRACE_BUFFER_FLUSH 수치가 계속 증가하고 있는 상태입니다.
exec sp_configure 'show advanced options',1
reconfigure
exec sp_configure 'default trace enabled',0
reconfigure
이 구문 이용해서 default trace enabled 값을 0으로 해주면 될까요??