Processor\%Processor Time : % Processor Time은 프로세서가 비유휴 스레드를 실행하는 데 소비하는 시간의 백분율입니다. 이것은 프로세서가 각 샘플 간격 동안 유휴 스레드를 실행하는 데 소비한 시간을 측정하여 간격 기간에서 그 값을 뺀 것입니다. 각 프로세서에는 유휴 스레드가 있는데 이것은 다른 어떤 스레드도 실행되지 않을 때 사이클을 소비하는 스레드입니다. 이 카운터는 프로세서 동작의 주요 표시기이며 샘플 간격 동안 관찰되는 사용 시간의 평균 백분율을 표시합니다. 이것은 서비스가 비활성인 시간을 모니터링하여 100%에서 그 값을 뺀 것입니다.


즉 쉽게 말해서, 1시간 동안 CPU상태를 관찰하였고, 1시간 중에서 30분간 CPU가 일을 하였다면, %Processor Time은 50% 입니다. 일반적으로 %Processor Time이 80%이상 사용되고 있으면, 관심을 가지고 사용량의 변화를 모니터하셔야 합니다.


Processor\%Privileged Time : % Privildged Time은 프로세스 스레드가 특권 모드에서 명령을 실행하면서 경과된 시간을 백분율로 표시한 것입니다. Windows 시스템 서비스가 호출되면, 서비스는 시스템 전용 데이터를 액세스하기 위해 흔히 특권 모드에서 실행됩니다. 그러한 데이터는 사용자 모드에서 실행되는 스레드가 액세스하지 못하도록 보호됩니다. 시스템 호출은 페이지 오류 또는 인터럽트가 발생할 때처럼 명시적이거나 암시적입니다. 일부 초기 운영 체제와는 달리 Windows는 사용자 및 특권 모드의 일반적인 보호뿐만 아니라 하위 시스템을 보호하기 위해 프로세스 경계를 사용합니다. 응용 프로그램을 대신하여 Windows에서 수행한 일부 작업은 프로세스의 특권 시간 및 다른 하위 시스템 프로세스에서도 나타납니다. 쉽게 말해서, 운영체제가 사용한 시간의 백분율 값입니다.


Memory\Available Bytes : Available Bytes는 컴퓨터에서 실행되는 프로세스에 사용할 수 있는 실제 메모리의 양(바이트)입니다. 이것은 0으로 채워 있거나 비어 있거나 대기 중인 메모리 목록에 있는 공간을 합해 계산합니다. 빈 메모리는 사용할 준비가 된 메모리이고, 0으로 채워진 메모리는 다음 프로세스가 이전 프로세스에서 사용된 데이터를 보지 못하도록 0으로 채운 메모리 페이지로 구성되며, 대기 메모리는 프로세스의 작업 집합(실제 메모리)에서 제거되어 디스크로 라우트되었지만 다시 호출되어 사용될 수 있는 메모리를 말합니다. 이 카운터는 최근에 관찰된 값만 표시하며 평균값은 아닙니다. 사용 가능한 여유 메모리는 많이 있으면 좋겠지만, 그렇지 않다면, 최소한 5Mbyte이상은 남아 있어야 합니다.


Memory\Page Faults/sec : Page Faults/sec는 프로세스가 사용하는 메모리 공간(Working Set)에 존재하지 않는 코드나, 데이터를 요청할 경우에 발생합니다. 이 때 요청된 코드나 데이터를 다른 메모리 공간에서 찾으면 Soft Page Fault라고 하며, 디스크에서 찾게되면 Hard Page Fault라고 합니다. Page Faults/sec은 초당 발생한 Soft Page Fault와 Hard Page Fault의 합입니다.

Soft Page Fault값은 Page Faults/sec값에서 Pages/sec값을 빼면 됩니다.


따라서,  Page Faults/sec의 값은 작을수록 좋다고 말 할 수 있겠으며, 상황에 따라서 그 임계치는 다르므로, 평상시에 모니터하여 적정 값을 파악해 두셔야 합니다. 


Memory\Pages/sec : Pages/sec는 하드 페이지 부재를 해결하기 위해 디스크에서 읽거나 디스크로 쓴 페이지의 비율입니다. 이것은 Memory\\Pages Input/sec과 Memory\\Pages Output/sec의 합입니다. 메모리 공간이 부족하게 되면, 디스크의 페이징 파일로 메모리의 내용을 옮겨서 메모리의 여유공간을 확보하여 사용하게 되며, 또 필요 시 페이징 파일에서 데이터를 메모리로 로드하여 처리하는 과정을 반복하게 되므로 성능이 저하되게 됩니다. 


Pages/sec 카운터 값이 20이상 지속되면 메모리 이상을 의심해야 합니다.


PhysicalDisk\%Disk Read Time : 디스크가 읽기 작업을 수행한 시간의 백분율입니다.


PhysicalDisk\%Disk Write Time : 디스크가 쓰기 작업을 수행한 시간의 백분율입니다.


PhysicalDisk\%Disk Time : 디스크가 읽기 및 쓰기 작업을 수행한 시간의 백분율이며, 이 값은 Disk Read Time과 Disk Write Time의 합입니다.


PhysicalDisk\Avg. Disk Queue Length : 디스크의 읽기 및 쓰기 작업을 위해 대기중인 실제 디스크 큐 길이 입니다. 이 값은 디스크당 2를 초과하게 되면, 디스크 쪽 부하를 점검해야 합니다.


PhysicalDisk\Current Disk Queue Length : 현재 시점의 디스크 읽기 및 쓰기 작업을 위해 대기중인 디스크 큐 길이 입니다. 이 값 역시 2를 초과하면, 디스크 쪽 부하를 점검해야 합니다.


Network Interface\Current Bandwidth : 네트워크 인터페이스의 현재 대역폭입니다. 사용하는 네트워크 어댑터 카드의 지원 가능 대역이 100Mbps인 경우에 Current Bandwidth값이 10Mbps라면 네트워크 어댑터 카드의 속성 세팅이 잘못 되었을 가능성이 큽니다.


Network Interface\Packets Outbound Errors : 이 항목은 오류로 인해서 외부로 반출할 수 없는 패킷의 수를 나타냅니다.


Network Interface\Packets Received Errors : 이 항목은 상위 계층의 프로토콜로 전달되지 못하도록 하는 오류를 포함하고 있는 외부로부터 유입되는 패킷의 수를 나타냅니다.


Server\Bytes Total/sec : 이 항목은 초당 서버가 네트워크에서 주고 받은 바이트 수 입니다. 동일 네트워크에 존재하는 서버들의 각각의 Bytes Total/sec 합이 네트워크 대역폭보다 크다면, 네트워크 분리를 고려하셔야 합니다.


SQLServer:Buffer Manager\Buffer cache hit ratio : SQL서버가 데이터를 디스크에서 읽지 않고 버퍼 풀에서 찾은 페이지 비율입니다. 이 값은 90% 이상 유지되어야 하며, 대부분의 시스템에서  98% 정도 유지 됩니다. 이 값이 90보다 낮다면 버퍼 공간이 부족하다고 판단할 수 있습니다.


SQLServer:Buffer Manager\Page life expectancy : 이 항목은 페이지가 참조되지 않고 얼마나 오랫동안 버퍼에 존재할 수 있는가를 초 단위로 나타냅니다. 이 값이 300초 이하이면, 성능향상을 위해  SQL서버에 추가적인 버퍼 공간이 필요하다고 볼 수 있습니다.


SQLServer:Buffer Manager\Page reads/sec : 모든 데이터베이스에 대해서 발생한 물리적 데이터 페이지의 초당 읽기 수를 나타냅니다. 물리적 I/O는 상대적으로 비용이 많이 발생하므로, 더 큰 데이터 캐시를 사용하거나, 인덱스 및 쿼리를 효율적으로 작성하거나, 데이터베이스 모델링을 다시하여 물리적 I/O비용을 줄여야 합니다.


SQLServer:Buffer Manager\Stolen Page : 윈도우 시스템이 SQL서버가 아닌 다른 응용 프로그램의 요구를 충족시키기 위하여 얼마나 많은 페이지들이 SQL Server 데이터 캐시로부터 제거되었는지를 나타낸다. min Server memory를 지정하여 SQL서버가 지정한 만큼의 SQL서버 전용으로 메모리를 할당하게 할 수 있지만, 그 만큼 다른 프로그램이 적은 메모리로 운영되게 되므로 페이징이 발생하게 됩니다. 따라서 메모리 증설을 고려해야 합니다.


SQLServer:Databases\Log Flushes/sec : 초당 발생한 로그 플러시 수를 나타냅니다. 하나의 로그플러시는 하나의 트랜잭션이 커밋되어 로그 파일에 기록되는 것을 의미 합니다.


SQLServer:Databases\Transactions/sec : 선택한 데이터 베이스에서 발생한 초당 발생하는 트랜잭션 수를 나타냅니다. 


SQLServer:General Statistics\User Connections : 시스템에 연결된 사용자 수를 나타냅니다.


SQL Server:Latches\Average Latch Wait Time(ms) : 요청된 래치에 대한 평균 래치 대기 시간(ms)


SQL Server:Latches\Latch Waits/sec : 즉시 서비스 될 수 없고 자원 해제를 위해 대기해야 하는 래치 요청 수


SQL Server: Locks\Average Wait Time(ms) : 리소스에 잠금을 걸기 위해  대기하였던 평균 시간(ms)을 나타냅니다.


SQL Server: Locks\Lock Timeouts/sec : 리소스에 잠금을 얻기 위해 대기하면서 타임 아웃된 잠금 요청 횟수를 나타냅니다.


SQL Server: Locks\Lock Waits/sec : 즉시 충족시킬 수 없고 잠금을 허가하기 위해서 호출자가 기다려야 하는 잠금 요청 수 


SQL Server: Locks\Number of Deadlocks/sec : 교착 상태를 일으킨 잠금 요청 수


SQL Server: Memory Manager\Memory Grants Pending : 작업 영역 메모리 허가를 위해 대기하고 있는 현재의 프로세스 수


SQL Server: Memory Manager\Target Server Memory(KB) : SQL Server가 사용할 수 있는 전체 메모리 양


SQL Server: Memory Manager\Total Server Memory(KB) : SQL Server가 사용하고 있는 전체 메모리 양


SQL Server: SQL Statistics\Batch Requests/sec : 초당 요청 받은 SQL 배치 요청 수


SQL Server: SQL Statistics\SQL Compilations/sec : 초당 SQL Server가 SQL문을 컴파일 한 수

 

 

SQL Server: SQL Statistics\Re-Compilations/sec : 초당 SQL Server가 SQL문을 재 컴파일 한 수





출처

http://sqler.pe.kr/web_board/view_list.asp?id=919&read=8898&pagec=17&gotopage=17&block=1&part=myboard7&tip=

저작자표시

'job > mssql' 카테고리의 다른 글

모니터링시 조치 방법  (0) 2018.08.31
병목현상 점검 조치  (0) 2018.08.31

출처 : http://tiger5net.egloos.com/5096569


분류항목임계값대처방법
MemoryAvailable Mbytes5MB 이하 (최소값)* 사용 가능한 물리적 메모리 용량
- Memory 20~25%보다 작은 값이 측정된다면, 특정 프로세스가 메모리누수를 발생시키고 있으므로 프로세스를 확인하거나 메모리증설
Page Faults/sec20* 초당 Page Fault 수
- 20이상이 되면 서버가 불안정
- 특히, 메모리 불량이거나 패리티에러가 발생하면 수치가 높아짐
- 웹서버는 보통 80~200은 정상으로 판단
Pages/sec20이상 : 경고
30이상 : 위험		* 초당 페이징 수
- SQL서버
1) Buffer Cache Hit Ratio도 이상이 있는 경우
    메모리증설 필요
2) Buffer Cache Hit Ratio에 이상이 없는 경우
    다른 Application의 영향 유무파악
    SQL서버 메모리구성 설정변경 (동적->고정)
- 일반서버
   Available Mbytes가 정상인데 임계치를 넘는 경우는 
   다른 Application에서 메모리관리를 잘못하는 경우임.
Pool Nonpaged 
Bytes		비정상 증가* 메모리 중 non-paged pool의 크기
- 유휴상태에서 해당값이 비정상적으로 증가한다면 
메모리누수
PhysicalDisk% Disk Time50%이상 : 경고
60%이상 : 위험		* Disk IO 사용율
- 임계치면 IO 과부하가 예상
- 논리파티션이나 개별 Disk의 값이 아닌 Disk Array 
전체의 값
- Array증설 필요
Avg. Disk 
Queue Length		2이상* Disk 대기열에 있는 IO요청 평균 수
- Array인 경우 임계치 산정은 Disk수 * 2
- Disk교체 or Array 구성이 아닐 경우 Array 구성
Processor% Processor Time70%이상 : 경고
80%이상 : 위험		* CPU 사용율
- 시스템에 의한 사용율 + 사용자에 의한 사용율
Interrupts/sec비정상 증가* 초당 인터럽트 횟수
- 네트웍카드와 같은 하드웨어에 문제가 생길 경우
  급증
ServerBytes Total/sec네트웍카드
최대 전송률		* 초당 전송바이트 수
- 장착된 네트웍카드의 최대 전송률과 비슷해지면 고  성능의 네트웍카드나 추가의 네트웍카드의 장착이 
필요
Pool Paged Peak물리적 메모리양* paged pool로 잡혔던 최대크기
- 해당값이 높다면 Application이 busy상태임.
- 메모리의 과부하로 이어지기 때문에 응용코드의 
  수정필요
Server Work
Queues		Queue Length4이상* CPU의 현재 작업큐의 길이
- 임계치 이상이면 CPU에 병목이 발생중임.
SQL Server:
Buffer Manager		Buffer cache 
hit ratio		90%이하* 메모리 접근 시 Disk가 아닌 Buffer를 사용하는 비율
- sqlserver.exe 프로세스의 메모리 사용을 체크하는 
  기준
- 메모리증설 필요
SQL Server:
General Statistics		User Connections255이상* DB Connection 수
- DB connection count >= SQL서버 max worker thread일 때, Connection당 1개씩의 worker thread
가 할당되어 가장 좋음
- 임계치 이상일 경우 "max worker threads" 
설정값을 늘림.
SystemProcessor Queue 
Length		2이상* CPU연산을 하기위한 Thread 대기 수
- 임계치 산정은 CPU수 * 2
- SQL서버
  1) CPU사용율이 낮으나 임계치를 벗어난 경우
      SQL서버의 "max worker threads" 설정값을 줄임.
  2) CPU사용율이 높거나 #1의 경우로 미해결인 경우
      CPU증설or thread수를 줄일 방법모색
- 일반서버
  1) CPU증설 or thread수를 줄일 방법모색
* 임계치 초과가 10분이상 지속된다면 H/W의 증설을 검토해야 함.


참고자료1 : SQL서버 진단을 위한 주요 성능카운터

참고자료2 : 서버 성능 평가
 

측정 대상 및 시기
리소스가 한도에 도달할 경우 전체 시스템 성능이 느려질 수 있는 병목 현상이 발생합니다. 병목 현상은 대체로 리소스 부족이나 잘못된 구성, 구성 요소 오작동 및 리소스에 대한 프로그램의 잘못된 요청 등으로 인해 발생합니다. 
 
병목 현상을 유발하고 서버 성능에 영향을 줄 수 있는 주요 리소스 영역은 물리적 디스크, 메모리, 프로세스, CPU, 네트워크 등의 5가지입니다. 이러한 리소스가 과도하게 사용되면 서버 또는 응용 프로그램이 현저하게 느려지거나 충돌이 발생할 수 있습니다. 이 문서에서는 이러한 5가지의 각 영역에서 사용해야 하는 카운터에 대해 소개하고 서버의 상태를 측정하는 데 권장되는 임계값을 제공합니다.
 
샘플링 간격은 로그 파일의 크기 및 서버 부하에 많은 영향을 주므로, 문제가 다시 발생하기 전에 기준을 설정할 수 있도록 문제가 발생하는 데 걸리는 평균 기간을 기준으로 샘플 간격을 설정해야 합니다. 그러면 문제로 이어지는 경향을 파악할 수 있습니다.
일반적인 작업 중 기준을 설정하기 위한 권장 시간은 15분입니다. 문제가 발생하는 데 걸리는 평균 시간이 약 4시간이라면 샘플 간격을 15초로 설정합니다. 문제가 발생하는 데 걸리는 시간이 8시간 이상이라면 샘플링 간격을 5분 이상으로 설정합니다. 그렇지 않으면 로그 파일이 너무 커져서 데이터를 분석하는 데 어려울 수 있습니다.


하드 디스크 병목 현상
디스크 시스템은 서버에서 프로그램 및 데이터를 저장하고 처리하므로 디스크 사용량 및 속도에 영향을 미치는 병목 현상은 서버의 전체적인 성능에 큰 영향을 줍니다. 
 
디스크 개체가 서버에서 비활성화된 경우 명령줄 도구 Diskperf를 통해 활성화해야 합니다. 또한 % Disk Time은 100%를 초과할 수 있으므로 대신 % Idle Time, Avg. Disk sec/Read 및 Avg. Disk sec/write를 사용하면 하드 디스크가 얼마나 많이 사용되고 있는지 좀더 정확하게 파악할 수 있습니다. % Disk Time에 대한 자세한 내용은 support.microsoft.com/kb/310067 기술 자료 문서를 참조하십시오. 
 
다음은 Microsoft Service Support 엔지니어가 디스크 모니터링을 위해 사용하는 카운터입니다.
 
LogicalDisk\% Free Space 선택한 논리 디스크 드라이브에서 사용할 수 있는 공간의 백분율을 측정합니다. 이 카운터가 15% 아래로 떨어지면 OS에서 중요 파일을 저장하기 위한 여유 공간이 부족할 수 있습니다. 이 경우 확실한 해결책은 디스크 공간을 늘리는 것입니다.
 
PhysicalDisk\% Idle Time 샘플 간격 중 디스크가 유휴 상태였던 시간 백분율을 측정합니다. 이 카운터가 20% 아래로 떨어지면 디스크 시스템이 포화 상태인 것입니다. 현재 디스크 시스템을 더 빠른 디스크 시스템으로 교체하는 것이 좋습니다.
 
PhysicalDisk\Avg. Disk Sec/Read 디스크에서 데이터를 읽는 데 걸리는 평균 시간(초)을 측정합니다. 값이 25ms(밀리초)보다 크면 디스크에서 읽을 때 디스크 시스템에 지연 현상이 발생하고 있음을 의미합니다. SQL Server® 및 Exchange Server를 호스팅하는 중요 업무 서버의 경우 허용 가능한 임계값은 10ms 미만입니다. 여기에서 가장 현명한 해결책은 현재 디스크 시스템을 더 빠른 디스크 시스템으로 교체하는 것입니다.
 
PhysicalDisk\Avg. Disk Sec/Write 디스크에 데이터를 쓰는 데 걸리는 평균 시간을 측정합니다. 이 시간이 25ms보다 크면 디스크에 쓸 때 디스크 시스템에 지연 현상이 발생하고 있음을 의미합니다. SQL Server 및 Exchange Server를 호스팅하는 중요 업무 서버의 경우 허용 가능한 임계값은 10ms 미만입니다. 여기에서 현명한 해결책은 디스크 시스템을 더 빠른 디스크 시스템으로 교체하는 것입니다.
 
PhysicalDisk\Avg. Disk Queue Length 얼마나 많은 I/O 작업이 하드 드라이브를 사용할 수 있을 때까지 대기하고 있는지 나타냅니다. 여기에서 값이 스핀들 수 + 2보다 크면 디스크 자체에 병목 현상이 있음을 의미합니다.
 
Memory\Cache Bytes 파일 시스템 캐시에 사용되고 있는 메모리의 양을 나타냅니다. 이 값이 200MB보다 크면 디스크 병목 현상이 발생할 수 있습니다.


메모리 병목 현상
메모리 부족은 대체로 RAM 부족, 메모리 누수 또는 boot.ini의 메모리 스위치 등으로 인해 발생합니다. 메모리 카운터를 소개하기 전에 먼저 /3GB 스위치에 대해 설명하겠습니다.
 
메모리가 많을수록 디스크 I/O 작업이 줄고 응용 프로그램 성능이 높아집니다. /3GB 스위치는 사용자 모드 프로그램에 더 많은 메모리를 제공하기 위한 방법으로 Windows NT®에서 도입되었습니다. 
 
Windows에서는 4GB의 가상 주소 공간을 사용하며 이는 시스템의 물리적 RAM과는 무관합니다. 기본적으로 하위 2GB는 사용자 모드 프로그램을 위해 사용되고, 상위 2GB는 커널 모드 프로그램을 위해 사용됩니다. /3GB 스위치를 사용하면 사용자 모드 프로세스에 3GB가 제공됩니다. 그러면 물론 커널 메모리가 가상 주소 공간의 1GB만 남게 되므로 영향을 받습니다. 이 경우 페이징되지 않은 바이트 풀링, 페이징된 바이트 풀링, 사용 가능한 시스템 페이지 테이블 항목 및 데스크톱 힙이 모두 이 1GB 공간 안에 들어가야 하므로 문제가 발생할 수 있습니다. 따라서 /3GB 스위치는 해당 환경에서 충분한 테스트를 거친 후에만 사용해야 합니다. 
 
메모리 관련 병목 현상이 발생하는 경우 이 스위치를 의심해 볼 수 있습니다. /3GB 스위치가 문제의 원인이 아니라면 다음 카운터를 사용하여 잠재적인 메모리 병목 현상을 진단할 수 있습니다.
 
Memory\% Committed Bytes in Use 커밋된 바이트와 커밋 한도의 비율, 즉 가상 메모리의 사용량을 측정합니다. 이 값이 80%보다 크면 메모리가 부족함을 나타냅니다. 이 경우 확실한 해결책은 메모리를 추가하는 것입니다. 
 
Memory\% Available Mbytes 프로세스 실행을 위해 사용할 수 있는 실제 메모리의 양(메가바이트)을 측정합니다. 이 값이 총 물리적 RAM의 5%보다 작으면 메모리가 부족함을 나타내며 이로 인해 페이징 작업이 늘어날 수 있습니다. 이 문제를 해결하려면 메모리를 추가해야 합니다. 

Memory\Free System Page Table Entries 시스템에서 현재 사용되지 않는 페이지 테이블 항목의 수를 나타냅니다. 이 숫자가 5,000보다 작으면 메모리 누수가 있을 수 있습니다. 
Memory\Pool Non-Paged Bytes 페이징되지 않은 풀의 크기(바이트)를 측정합니다. 디스크에 쓸 수 없고 대신 실제 메모리에 남아 있어야 하는 할당된 개체에 대한 시스템 메모리 영역입니다. 이 값이 175MB(또는 /3GB 스위치의 경우 100MB)보다 크면 메모리 누수 가능성이 있습니다. 일반적인 이벤트 ID 2019가 시스템 이벤트 로그에 기록됩니다.
 
Memory\Pool Paged Bytes 페이징된 풀의 크기(바이트)를 측정합니다. 사용되고 있지 않을 때 디스크에 쓸 수 있는 개체에 대한 시스템 메모리 영역입니다. 이 값이 250MB(또는 /3GB 스위치의 경우 170MB)보다 크면 메모리 누수 가능성이 있습니다. 일반적인 이벤트 ID 2020이 시스템 이벤트 로그에 기록됩니다.
 
Memory\Pages per Second 하드 페이지 결함을 해결하기 위해 디스크에서 페이지를 읽거나 쓰는 속도를 측정합니다. 과도한 페이징으로 인해 이 값이 1,000보다 크면 메모리 누수 가능성이 있습니다.


프로세서 병목 현상
프로세서 병목 현상은 프로세서 자체의 성능이 나빠서 발생하거나 비효율적인 응용 프로그램으로 인해 발생할 수 있습니다. 실제 메모리 부족으로 인해 프로세서가 페이징에서 많은 시간을 보내지 않는지 다시 확인해야 합니다. 잠재적인 프로세서 병목 현상을 조사할 때 Microsoft Service Support 엔지니어는 다음 카운터를 사용합니다. 
 
Processor\% Processor Time 프로세서가 비유휴 스레드 실행에 소비하는 경과 시간의 백분율을 측정합니다. 이 백분율이 85%보다 크면 프로세서에 병목 현상이 발생하고 서버에 더 빠른 프로세서가 필요할 수 있습니다. 
 
Processor\% User Time 프로세서가 사용자 모드에서 소비하는 경과 시간의 백분율을 측정합니다. 이 값이 높으면 서버에서 응용 프로그램이 많이 실행되고 있음을 나타냅니다. 한 가지 가능한 해결책은 프로세서 리소스를 많이 사용하는 응용 프로그램을 최적화하는 것입니다.
 
Processor\% Interrupt Time 지정된 샘플 간격 중 프로세서가 하드웨어 인터럽트 수신 및 서비스 제공에 소비하는 시간을 측정합니다. 이 값이 15%보다 크면 하드웨어 문제일 수 있습니다.
 
System\Processor Queue Length 프로세서 큐의 스레드 수를 나타냅니다. 이 값이 일정 기간 동안 CPU 수 x 2보다 크면 서버에 프로세서 성능이 부족한 것입니다.


네트워크 병목 현상
네트워크 병목 현상은 네트워크에서 데이터를 송수신하는 서버의 성능에 영향을 미칩니다. 서버의 네트워크 카드에 문제가 있을 수 있거나, 네트워크가 포화 상태여서 분할해야 할 수 있습니다. 다음 카운터를 사용하여 잠재적인 네트워크 병목 현상을 진단할 수 있습니다.
 
Network Interface\Bytes Total/Sec 프레이밍 문자를 포함하여 각 네트워크 어댑터를 통해 보내고 받는 바이트의 비율을 측정합니다. 인터페이스의 70% 이상이 사용되면 네트워크가 포화 상태입니다. 100Mbps NIC의 경우 사용되는 인터페이스는 8.7MB/초입니다(100Mbps = 100000kbps = 12.5MB/초* 70%). 이와 같이 포화 상태이면 더 빠른 네트워크 카드를 추가하거나 네트워크를 분할해야 할 수 있습니다.
 
Network Interface\Output Queue Length 출력 패킷 큐의 길이(패킷)를 측정합니다. 이 값이 2보다 크면 네트워크가 포화 상태입니다. 이 문제는 더 빠른 네트워크 카드를 추가하거나 네트워크를 분할하여 해결할 수 있습니다.


프로세스 병목 현상
제대로 작동하지 않는 프로세스나 최적화되지 않은 프로세스가 있으면 서버 성능이 크게 저하될 수 있습니다. 스레드 및 핸들 누수는 결국 서버 다운으로 이어지고, 과도한 프로세서 사용은 서버 속도를 저하시킵니다. 다음 카운터는 프로세스 관련 병목 현상을 진단할 때 유용합니다.
 
Process\Handle Count 프로세스로 현재 열린 총 핸들 수를 측정합니다. 이 값이 10,000보다 크면 핸들 누수 가능성이 있습니다. 
 
Process\Thread Count 프로세스에서 현재 활성 스레드 수를 측정합니다. 이 값이 최소 및 최대 스레드 수 사이에서 500보다 크면 스레드 누수 가능성이 있습니다. 
 
Process\Private Bytes 다른 프로세스와 공유할 수 없는 이 프로세스에 할당된 메모리의 양입니다. 이 값이 최소 및 최대 스레드 수 사이에서 250보다 크면 메모리 누수 가능성이 있습니다.


요약
지금까지 Microsoft의 Service Support 엔지니어가 다양한 병목 현상을 진단하기 위해 사용하는 카운터를 살펴보았습니다. 물론 결국에는 자신의 특정 요구에 맞는 고유의 카운터를 사용해야 합니다. 또한 서버를 모니터링해야 할 때마다 모든 카운터를 수동으로 추가할 필요가 없게 해야 합니다. 다행히 성능 모니터에는 나중에 사용하기 위해 템플릿에 모든 카운터를 저장할 수 있는 옵션이 있습니다. 
 
성능 모니터를 로컬에서 실행해야 하는지 아니면 원격으로 실행해야 하는지 결정하지 못할 수 있습니다. 또한 성능 모니터를 로컬에서 실행할 때 성능에 정확히 어떤 영향을 주는지도 확실하지 않을 경우가 있습니다. 이 모든 사항은 특정 환경에 따라 다릅니다. 간격을 5분 이상으로 설정한다면 서버에서의 성능 저하는 거의 무시할 만한 수준입니다. 
 

성능 모니터는 서버에 리소스가 부족할 때 원격 시스템에서 데이터를 가져오지 못할 수 있으므로 서버에 성능 문제가 있음을 알고 있다면 성능 모니터를 로컬에서 실행하는 것이 좋습니다. 중앙 컴퓨터에서 원격으로 실행하는 것은 여러 서버를 모니터링하거나 기준으로 사용하고자 할 때 가장 이상적입니다. 

저작자표시

'job > mssql' 카테고리의 다른 글

mssql 튜닝을위한 성능 모니터  (0) 2018.08.31
병목현상 점검 조치  (0) 2018.08.31

펌 : http://www.uhoon.co.kr/mssql/2309


참고 Url 

http://technet.microsoft.com/ko-kr/library/bb838723(v=office.12).aspx (SQL Server 상태 모니터링)

http://technet.microsoft.com/ko-kr/library/bb510705(v=sql.105).aspx (모니터링(데이터베이스 엔진))



일전에 사내 디비서버 성능저하 현상으로 상태 체크하는 방법을 찾다가 알게된 정보입니다.

결과적으로는 별로 사용해보지 못했으나 유용한 정보입니다.

( 성능 저하 문제는 RAID IO 비율 하드웨어 셋팅 문제였다는.. HP .. Accelerator ratio Read/Write 비율 설정하는 옵션이 있더군요.. ..)



SQL Server 상태를 모니터링하기 위해 동적 관리 뷰 및 함수에 대해 일반적으로 사용하는 몇 가지 쿼리들..



- CPU 병목 현상 모니터링

CPU 병목 현상은 일반적으로 최적화되지 않은 쿼리 계획, 잘못된 구성, 잘못된 디자인 요소 또는 충분하지 않은 하드웨어 리소스 등으로 인해 발생합니다. 

다음은 CPU 병목 현상을 일으키는 원인을 찾아내기 위해 일반적으로 사용되는 몇 가지 쿼리입니다.

다음 쿼리를 실행하면 현재 캐시된 배치나 프로시저 중 CPU 사용률이 가장 높은 항목이 무엇인지 쉽게 파악할 수 있습니다.


?
1
2
3
4
5
6
7
8
SELECT TOP 50
      SUM(qs.total_worker_time) AS total_cpu_time,
      SUM(qs.execution_count) AS total_execution_count,
      COUNT(*) AS  number_of_statements,
      qs.sql_handle
FROM sys.dm_exec_query_stats AS qs
GROUP BY qs.sql_handle
ORDER BY SUM(qs.total_worker_time) DESC


다음 쿼리는 SQL 텍스트를 사용하여 캐시된 계획별로 집계한 CPU 사용량을 보여 줍니다.

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
SELECT
      total_cpu_time,
      total_execution_count,
      number_of_statements,
      s2.text
      --(SELECT SUBSTRING(s2.text, statement_start_offset / 2, ((CASE WHEN statement_end_offset = -1 THEN (LEN(CONVERT(NVARCHAR(MAX), s2.text)) * 2) ELSE statement_end_offset END) - statement_start_offset) / 2) ) AS query_text
FROM
      (SELECT TOP 50
            SUM(qs.total_worker_time) AS total_cpu_time,
            SUM(qs.execution_count) AS total_execution_count,
            COUNT(*) AS  number_of_statements,
            qs.sql_handle --,
            --MIN(statement_start_offset) AS statement_start_offset,
            --MAX(statement_end_offset) AS statement_end_offset
      FROM
            sys.dm_exec_query_stats AS qs
      GROUP BY qs.sql_handle
      ORDER BY SUM(qs.total_worker_time) DESC) AS stats
      CROSS APPLY sys.dm_exec_sql_text(stats.sql_handle) AS s2


다음 쿼리는 평균 이상의 CPU 사용률을 보이는 상위 50개 SQL 문을 보여 줍니다.

?
1
2
3
4
5
SELECT TOP 50
total_worker_time/execution_count AS [Avg CPU Time],
(SELECT SUBSTRING(text,statement_start_offset/2,(CASE WHEN statement_end_offset = -1 then LEN(CONVERT(nvarchar(max), text)) * 2 ELSE statement_end_offset end -statement_start_offset)/2) FROM sys.dm_exec_sql_text(sql_handle)) AS query_text, *
FROM sys.dm_exec_query_stats
ORDER BY [Avg CPU Time] DESC


다음은 과도한 컴파일/재컴파일을 찾기 위한 DMV 쿼리입니다.

?
1
2
3
4
select * from sys.dm_exec_query_optimizer_info
where
      counter = 'optimizations'
      or counter = 'elapsed time'


다음 샘플 쿼리에서는 다시 컴파일된 상위 25개의 저장 프로시저를 표시합니다. plan_generation_num은 쿼리를 다시 컴파일한 횟수를 나타냅니다.

?
1
2
3
4
5
6
7
8
9
10
11
select top 25
      sql_text.text,
      sql_handle,
      plan_generation_num,
      execution_count,
      dbid,
      objectid
from sys.dm_exec_query_stats a
      cross apply sys.dm_exec_sql_text(sql_handle) as sql_text
where plan_generation_num > 1
order by plan_generation_num desc


쿼리 계획이 충분하지 않으면 CPU 사용량이 증가할 수 있습니다.
다음 쿼리에서는 가장 많은 누적 CPU 사용량을 보이는 쿼리를 표시합니다.
?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
SELECT
    highest_cpu_queries.plan_handle,
    highest_cpu_queries.total_worker_time,
    q.dbid,
    q.objectid,
    q.number,
    q.encrypted,
    q.[text]
from
    (select top 50
        qs.plan_handle,
        qs.total_worker_time
    from
        sys.dm_exec_query_stats qs
    order by qs.total_worker_time desc) as highest_cpu_queries
    cross apply sys.dm_exec_sql_text(plan_handle) as q
order by highest_cpu_queries.total_worker_time desc


다음 쿼리에서는 '%Hash Match%', '%Sort%' 등과 같이 CPU를 집중적으로 사용할 수 있는 몇 가지 의심해볼 만한 연산자를 표시합니다.

?
1
2
3
4
5
6
7
select *
from
      sys.dm_exec_cached_plans
      cross apply sys.dm_exec_query_plan(plan_handle)
where
      cast(query_plan as nvarchar(max)) like '%Sort%'
      or cast(query_plan as nvarchar(max)) like '%Hash Match%'

쿼리 계획이 충분하지 않아 CPU 사용량이 높아졌다는 사실을 확인했다면 쿼리에 관련된 테이블에 대해 UPDATE STATISTICS를 실행하고 문제가 지속되는지 확인합니다.
그런 다음 데이터를 수집하고 그 문제를 PerformancePoint 계획 지원 센터에 보고합니다.
시스템에서 컴파일과 재컴파일이 과도하게 이루어지면 시스템의 CPU 관련 성능에 문제가 발생할 수 있습니다.
다음 DMV 쿼리를 실행하면 과도한 컴파일/재컴파일을 찾아낼 수 있습니다.
?
1
2
3
4
select * from sys.dm_exec_query_optimizer_info
where
counter = 'optimizations'
or counter = 'elapsed time'


다음 샘플 쿼리에서는 다시 컴파일된 상위 25개의 저장 프로시저를 표시합니다. plan_generation_num은 쿼리를 다시 컴파일한 횟수를 나타냅니다.

?
1
2
3
4
5
6
7
8
9
10
11
select top 25
sql_text.text,
sql_handle,
plan_generation_num,
execution_count,
dbid,
objectid
from sys.dm_exec_query_stats a
cross apply sys.dm_exec_sql_text(sql_handle) as sql_text
where plan_generation_num > 1
order by plan_generation_num desc



- 메모리 병목 현상

메모리 부족 문제에 대한 감지와 조사를 시작하려면 먼저 SQL Server에서 고급 옵션을 활성화해야 합니다. 마스터 데이터베이스에 대해 다음 쿼리를 실행하여 우선 이 옵션을 활성화합니다.


?
1
2
3
4
5
6
sp_configure 'show advanced options'
go
sp_configure 'show advanced options', 1
go
reconfigure
go


다음 쿼리를 실행하여 메모리 관련 구성 옵션을 먼저 검사합니다.

?
1
2
3
4
5
6
7
8
9
10
sp_configure 'awe_enabled'
go
sp_configure 'min server memory'
go
sp_configure 'max server memory'
go
sp_configure 'min memory per query'
go
sp_configure 'query wait'
go


다음 DMV 쿼리를 실행하여 CPU, 스케줄러 메모리 및 버퍼 풀 정보를 확인합니다.

?
1
2
3
4
5
6
7
8
9
10
select
cpu_count,
hyperthread_ratio,
scheduler_count,
physical_memory_in_bytes / 1024 / 1024 as physical_memory_mb,
virtual_memory_in_bytes / 1024 / 1024 as virtual_memory_mb,
bpool_committed * 8 / 1024 as bpool_committed_mb,
bpool_commit_target * 8 / 1024 as bpool_target_mb,
bpool_visible * 8 / 1024 as bpool_visible_mb
from sys.dm_os_sys_info



- I/O 병목 현상

I/O 병목 현상은 래치 대기 시간을 조사하여 확인합니다. 다음 DMV 쿼리를 실행하여 I/O 래치 대기 시간에 대한 통계를 확인합니다.


?
1
2
3
4
select wait_type, waiting_tasks_count, wait_time_ms, signal_wait_time_ms, wait_time_ms / waiting_tasks_count
from sys.dm_os_wait_stats 
where wait_type like 'PAGEIOLATCH%'  and waiting_tasks_count > 0
order by wait_type


waiting_task_counts 및 wait_time_ms가 평상시와 비교하여 크게 달라졌으면 I/O 문제가 있는 것입니다. 이 비교를 위해서는 SQL Server가 안정적으로 실행되고 있을 때 성능 카운터와 주요 DMV 쿼리 출력의 기준선을 마련해 두는 것이 중요합니다.
이러한 wait_types를 살펴보면 I/O 하위 시스템이 병목 현상을 겪고 있는지 알 수 있습니다.
다음 DMV 쿼리를 사용하면 현재 보류 중인 I/O 요청을 확인할 수 있습니다. 이 쿼리를 정기적으로 실행하여 I/O 하위 시스템의 상태를 점검하고 I/O 병목 현상에 관련된 물리적 디스크를 격리하십시오.

?
1
2
3
4
5
6
7
8
9
select
    database_id,
    file_id,
    io_stall,
    io_pending_ms_ticks,
    scheduler_address
from  sys.dm_io_virtual_file_stats(NULL, NULL)t1,
        sys.dm_io_pending_io_requests as t2
where t1.file_handle = t2.io_handle

정상적인 상태에서는 대개 쿼리를 실행해도 아무 것도 반환되지 않습니다. 만일 이 쿼리에서 어떤 행이 반환된다면 더 자세한 조사를 해볼 필요가 있습니다.
다음 DMV 쿼리를 실행하여 I/O 관련 쿼리를 찾을 수도 있습니다.
?
1
2
3
4
5
6
7
8
select top 5 (total_logical_reads/execution_count) as avg_logical_reads,
                   (total_logical_writes/execution_count) as avg_logical_writes,
           (total_physical_reads/execution_count) as avg_physical_reads,
           Execution_count, statement_start_offset, p.query_plan, q.text
from sys.dm_exec_query_stats
      cross apply sys.dm_exec_query_plan(plan_handle) p
      cross apply sys.dm_exec_sql_text(plan_handle) as q
order by (total_logical_reads + total_logical_writes)/execution_count Desc


다음 DMV 쿼리를 사용하면 가장 많은 I/O를 생성하는 배치/요청이 무엇인지 찾을 수 있습니다. 

다음과 같은 DMV 쿼리를 사용하면 가장 많은 I/O를 생성하는 상위 5개 요청을 찾을 수 있습니다.

이러한 쿼리를 조정하여 시스템 성능을 향상시킬 수 있습니다.

?
1
2
3
4
5
6
7
8
9
10
select top 5
    (total_logical_reads/execution_count) as avg_logical_reads,
    (total_logical_writes/execution_count) as avg_logical_writes,
    (total_physical_reads/execution_count) as avg_phys_reads,
     Execution_count,
    statement_start_offset as stmt_start_offset,
    sql_handle,
    plan_handle
from sys.dm_exec_query_stats 
order by  (total_logical_reads + total_logical_writes) Desc



- 차단


다음 쿼리를 실행하면 차단 세션을 확인할 수 있습니다.

?
1
2
3
select blocking_session_id, wait_duration_ms, session_id from
sys.dm_os_waiting_tasks
where blocking_session_id is not null


이 호출을 사용하면 blocking_session_id를 통해 반환되는 SQL을 찾을 수 있습니다. 예를 들어 blocking_session_id가 87인 경우 SQL을 확인하려면 다음 쿼리를 실행합니다.

?
1
dbcc INPUTBUFFER(87)


다음 쿼리에서는 SQL 대기 상태 분석 및 대기 중인 상위 10개 리소스를 표시합니다.

?
1
2
3
4
select top 10 *
from sys.dm_os_wait_stats
--where wait_type not in ('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE','SLEEP_TASK','SLEEP_SYSTEMTASK','WAITFOR')
order by wait_time_ms desc


어떤 spid가 다른 spid를 차단하고 있는지 확인하려면 데이터베이스에 다음과 같은 저장 프로시저를 만들어 실행합니다.

이 저장 프로시저는 차단 상황을 보고합니다. 

@spid를 알아내려면 sp_who를 입력합니다. @spid는 선택적 매개 변수입니다.

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
create proc dbo.sp_block (@spid bigint=NULL)
as
select
    t1.resource_type,
    'database'=db_name(resource_database_id),
    'blk object' = t1.resource_associated_entity_id,
    t1.request_mode,
    t1.request_session_id,
    t2.blocking_session_id   
from
    sys.dm_tran_locks as t1,
    sys.dm_os_waiting_tasks as t2
where
    t1.lock_owner_address = t2.resource_address and
    t1.request_session_id = isnull(@spid,t1.request_session_id)


다음은 이 저장 프로시저를 사용하는 예제입니다.

?
1
2
exec sp_block
exec sp_block @spid = 7


저작자표시

'job > mssql' 카테고리의 다른 글

mssql 튜닝을위한 성능 모니터  (0) 2018.08.31
모니터링시 조치 방법  (0) 2018.08.31

+ Recent posts

티스토리툴바