모니터링시 조치 방법

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

분류	항목	임계값	대처방법
Memory	Available Mbytes	5MB 이하 (최소값)	* 사용 가능한 물리적 메모리 용량 - Memory 20~25%보다 작은 값이 측정된다면, 특정 프로세스가 메모리누수를 발생시키고 있으므로 프로세스를 확인하거나 메모리증설
	Page Faults/sec	20	* 초당 Page Fault 수 - 20이상이 되면 서버가 불안정 - 특히, 메모리 불량이거나 패리티에러가 발생하면 수치가 높아짐 - 웹서버는 보통 80~200은 정상으로 판단
	Pages/sec	20이상 : 경고 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 Time	50%이상 : 경고 60%이상 : 위험	* Disk IO 사용율 - 임계치면 IO 과부하가 예상 - 논리파티션이나 개별 Disk의 값이 아닌 Disk Array  전체의 값 - Array증설 필요
	Avg. Disk  Queue Length	2이상	* Disk 대기열에 있는 IO요청 평균 수 - Array인 경우 임계치 산정은 Disk수 * 2 - Disk교체 or Array 구성이 아닐 경우 Array 구성
Processor	% Processor Time	70%이상 : 경고 80%이상 : 위험	* CPU 사용율 - 시스템에 의한 사용율 + 사용자에 의한 사용율
	Interrupts/sec	비정상 증가	* 초당 인터럽트 횟수 - 네트웍카드와 같은 하드웨어에 문제가 생길 경우   급증
Server	Bytes Total/sec	네트웍카드 최대 전송률	* 초당 전송바이트 수 - 장착된 네트웍카드의 최대 전송률과 비슷해지면 고  성능의 네트웍카드나 추가의 네트웍카드의 장착이  필요
	Pool Paged Peak	물리적 메모리양	* paged pool로 잡혔던 최대크기 - 해당값이 높다면 Application이 busy상태임. - 메모리의 과부하로 이어지기 때문에 응용코드의    수정필요
Server Work Queues	Queue Length	4이상	* CPU의 현재 작업큐의 길이 - 임계치 이상이면 CPU에 병목이 발생중임.
SQL Server: Buffer Manager	Buffer cache  hit ratio	90%이하	* 메모리 접근 시 Disk가 아닌 Buffer를 사용하는 비율 - sqlserver.exe 프로세스의 메모리 사용을 체크하는    기준 - 메모리증설 필요
SQL Server: General Statistics	User Connections	255이상	* DB Connection 수 - DB connection count >= SQL서버 max worker thread일 때, Connection당 1개씩의 worker thread 가 할당되어 가장 좋음 - 임계치 이상일 경우 "max worker threads"  설정값을 늘림.
System	Processor 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분 이상으로 설정한다면 서버에서의 성능 저하는 거의 무시할 만한 수준입니다. 
 

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