개요

1. DB 레벨이 아닌 대/소규모 서비스 레벨 테스트가 진행될 경우

DB단의 성능이슈 (리소스,트랜잭션 처리)가 없는지 확인이 필요 

2. 모니터링방법이 테스트에 큰 영향을 미치지 않아야함

3. 테스트간 SQL Server 서비스 재기동 (warm-up 방지 및 DMV 지표 초기화 등)

4. 지연의 원인은 매우 광범위하여 가급적 넓은 범위에 대한 데이터 확인이 필요

 

모니터링 (Query)

Batch Resp Statistics: Ealpsed Time 체크

   - trace는 테스트 자체에 영향을 미칠 가능성이 높음

   - 백그라운드 트랜잭션에 의한 Value가 증가하지만, 대량의 트래픽이 유입된다는 가정하에 신뢰할만한 데이터

  : [스크립트] Adhoc/Proc 실시간or 통계 조회 :: 일상및기술기록 (tistory.com) 내 'Batch Resp Statistics: Ealpsed Time 체크'

타겟 Proc 통계 조회 (실시간 or 테스트 종료시)

   : [스크립트] Adhoc/Proc 실시간or 통계 조회 :: 일상및기술기록 (tistory.com) 내 'Proc 통계 조회'

Latch 통계 조회 (실시간 or 테스트 종료시)

  : [스크립트] 실시간/통계 latch&lock 확인 :: 일상및기술기록 (tistory.com) 내 'latch/lock 통계', 'object 별 latch/lock 통계'

Active Session Lock or 지연 조회 (실시간) 

  : [스크립트] Adhoc/Proc 실시간or 통계 조회 :: 일상및기술기록 (tistory.com) 내 '실시간 트랜잭션 조회'

Latch 실시간 조회 (실시간)

  - pagelatch는 일반적으로(주관) 아래 상태 의심시 체크할 수 있으며 실시간 조회가 큰 의미는 없다고 개인적으로 생각

     1. identity 속성의 영향

     2. 과도한 CPU Core 사용

     3. User Connection이 급증

  :  [스크립트] Adhoc/Proc 실시간or 통계 조회 :: 일상및기술기록 (tistory.com) 내 '실시간 latch'

 

 

모니터링 (Perfmon)

일반적인 상황

perfmon_1.xml
0.01MB

더 많은 지표 수집 필요한 상황

   - perfmon_x1.xml에 추가로 네트워크 상태나 각 DB/DISK 리소스에 대한 보다 상세 정보 필요시

perfmon_2.xml
0.01MB

+ Recent posts