1. 성능 모니터 체크 카운터 정리
1.1 Processor
1.1.1 %Processor Time
비유휴 스레드를 실행하는 cpu 소비하는 시간의 백분율
Ex) 1시간 동안 CPU상태를 관찰하였고, 1시간 중 30분간 CPU가 일을 하였다면, %Processor Time = 50%
임계점 = 70% 이상 경고, 80% 이상 위험
1.1.2 %Privileged Time
프로세스 스레드가 특권 모드에서 명령을 실행하면서 경과된 시간을 백분율로 표시
운영체제가 사용한 시간의 백분율
임계점 = 70% 이상 경고, 80% 이상 위험
1.1.3 Interrupts/sec
초당 인터럽스 횟수
네트워크카드와 같은 하드웨어에 문제가 생길경우 급증
PhysicalDisk의 객체카운터를 모니터링
임계점 = 비정상 증가(7000 이상)
1.1.4 %Interrrupt Time
프로세스가 하드웨어 인터럽트를 처리하는 데 소비된 시간의 백분율
임계점 : 5
1.1.5 %User Time
수행되고 있는 애플리케이션이 사용하고 있는 CPU 사용률
임계점 : 80 이상
1.2 Memory
1.2.1 Available Bytes
컴퓨터에서 실행되는 프로세스에 사용할 수 있는 실제 메모리양(바이트)
임계점 : 전체 메모리 크기의 5% 이하일 때
1.2.2 Page Faults/sec
프로세스가 사용하는 메모리 공간(Working Set)에 존재하지 않는 코드나, 데이터를 요청할 경우 발생, 작을수록 좋고 상황에 따라서 임계치가 다름.
1.2.3 Pages/sec
하드 페이지 부재를 해결하기 위해 디스크에서 읽거나 디스크로 쓴 페이지 비율
메모리 공간이 부족하게 되면, 디스크의 페이징 파일로 메모리의 내용을 옮겨서 메모리의 여유간을 확보하여 사용하게 되며, 또 필요 시 페이징 파일에서 데이터를 메모리로 로드하여 처리하는 과정을 반복하게 되므로 성능 저하 발생
5보다 작을 것을 권장
임계점 : 20이상 경고, 30이상 위험
1.2.4 Cache Faults/sec
Cache Manager가 즉각적인 캐쉬에서 페이지를 찾지 못할 때 발생
임계점 : 100이상
1.3 PhysicalDisk
1.3.1 Disk Time
디스크가 읽기 및 쓰기 작업을 수행한 시간의 백분율
Disk Time = (Physical % Logical)
임계점 : 50%이상 경고, 60%이상 위험
1.3.2 Avg. Disk Queue Length
디스크의 읽기 및 쓰기 작업을 위해 대기중인 디스크 큐의 길이
Array인 경우 임계치 산정은 Disk수 * 2
임계점 : 2이상
1.3.3 Current Disk Queue Length
현재 시점의 디스크 읽기 및 쓰기 작업을 위해 대기 중인 디스크 큐의 길이
이 카운터는 순간 카운터이다. 순간적으로 수치가 높게 나온다고 해서 문제가 있다고 판단할 수는 없으며, 장시간 측정할 필요가 있다.
임계점 : 2이상
1.4 System
1.4.1 Processor Queue Length
프로세서 주기를 기다리며 대기하는 스레드 수의 순간적인(평균이 아닌) 계산.
임계점 : 2보다 작아야 한다.
1.4.2 Context Switches/sec
컴퓨터의 모드 프로세서가 한 스레드에서 다른 스레드로 전환한 횟수
임계점 : CPU당 5000이 넘게 되면, Resource Contention Problem 발생
1.5 Network Interface
1.5.1 Bytes Total/sec
프레이밍 문자를 포함하여 각 네트워크 어댑터를 통해 보내고 받는 바이트의 비율을 측정
계산법 : (100Mbps = 1000000kbps = 12.5MB/초) * 70% = 8.7MB/초
임계점 : 70%
1.5.2 Output Queue Length
출력 패킷 큐의 길이
임계점 : 2
1.6 SQL Server
1.6.1 Buffer Manager : Buffer Cache Hit Ratio
SQL 서버가 데이터를 디스크에서 읽지 않고 버퍼풀에서 찾은 페이지 비율
캐쉬 적중률 : 90% 이상 권장(OLTP는 99%이상 권장 - 게임은 기본적으로 OLTP)
임계점 : 80%이하
1.6.2 Locks : Number of DeadLock/sec
교착 상태를 일으킨 잠금 수
1.6.3 SQL Statistics : Batch Requests/sec
초당 요청 받은 SQL 배치 요청 수
1.6.4 SQL Statistics : SQL Compilation/sec
초당 SQL Server가 SQL문을 컴파일 한 수
1.6.5 SQL Statistics : Re- Compilation/sec
초당 SQL Server가 SQL문을 재 컴파일 한 수
1.6.6 SQL Statistics : Pages Splits/sec
페이지 스플릿 발생 수
2. 예상 병목 상황
2.1 CPU 병목 현상
프로세서 병목 현상은 프로세서 자체의 성능이 나쁘서 발생하거나 비효율적인 응용 프로그램으로 인해 발생할 수 있음, 실제 메모리 부족으로 인해 프로세서가 페이징에서 많은 시간을 보내지 않지 확인해야 함.
2.2 Memory 병목 현상
대체로 RAM 부족, 메모리 누수에 의해 발생, /3GB 스위치 사용자일 수 있음
/3GB 스위치
= Windows에서는 4GB의 가상 주소 공간을 사용하며 이는 시스템의
물리적 RAM과는 무관. 기본적으로 하위 2GB는 사용자 모드 프로그램을 위해 사용되고
상위 2GB는 커널 모드 프로그램을 위해 사용되는데 /3GB 스위치는 커널모드의 1GB를 사용자 모드로 전황 1:3 으로 만들어 사용
2.3 네트워크 병목 현상
네트워크에서 송수신하는 서버의 성능에 영향을 미침
네트워크 카드에 문제가 있거나 네트워크가 포화 상태여서 분항해야 할 수 있음
3. SQL Server Profiler와 연동
3.1.1 추적 설정
A. 프로파일러로 추적을 실행한다.
B. A.방법이 아니라면 Trace DMV를 통해 추적을 실시한다.
C. 추적을 멈추고 해당 추적 파일에 해당 admin의 등록을 추가한다.
3.1.2 성능 카운터 설정
A. 사용자 정의 -> 오른쪽 버튼 -> 새로만들기 -> 데이터 수집기 집합
B. 기존에 사용되는 Template이나 새로 추가한 성능 카운터를 추가한다.
찾아보기 버튼 후 템플릿 xml 파일을 등록한다
또는
수동으로 만들기 선택 ->
후 카운터를 등록한다.
3.1.3 추적과 성능 카운터 연동
A. 추적 파일을 연다.
B. 파일 -> 성능 데이터 가져오기
C. 해당 아래 그림처럼 해당 쿼리가 실행되었을 때
템플릿의 그래프를 확인할 수 있음
'Database > SQL Server' 카테고리의 다른 글
확장 이벤트를 통한 Dead Lock 캡처 (0) | 2021.04.22 |
---|---|
Lock 과 DeadLock (0) | 2021.04.22 |
Flyway 이용한 형상관리 (0) | 2021.04.16 |
SQL Server Graph DB 간단한 테스트 (0) | 2021.04.15 |
SQL Server Monitoring (0) | 2021.04.14 |
최근댓글