성능모니터 관련

http://whitelotos.blog.me/70047831380

윈도우즈 환경에서 테스트 하는 경우, 마이크로소프트에서 제공하는 성능모니터 만큼 적당한게 없는 것 같아서,

일단 필요한 내용을 검색 후 테스트 해 보고 정리합니다.

그냥 제가 정리해놓고 계속 사용하면서 업데이트 하도록 하겠습니다. 원래, 자기가 써보지 않으면

절대로 알수 없는 게 이 분야의 속성이죠... 모르면서 아는체 하면 항상 강호의 고수에게 당하는 법... ^^;;

하수가 정리하는 거니까 잘못된 부분에 대해서는 날카로운 지적을 부탁드립니다.... -_-;;;

2005년도에 작성된 내용을 보면서 일단 정리 하고, 제가 체크를 좀더 해보고 있습니다... 안 맞는 부분도 약간 있는 듯 하더군요...

뭐, 제가 틀렸을 수도 있습니다....

성능 모니터 주요 체크 카운터

1. 메모리 사용량
1.1 memory

시스템 운영에서 사용 가능한 실제 총 메모리를 측정하고 서버에서 모든 프로세스와
응용 프로그램을 실행하는데 필요한 메모리와 비교하십시오. 적어도 최고 사용 상태에서
사용할 수 있는 메모리의 10%를 유지 하십시오. 기본적을 IIS 5.6은 서버 컴퓨터에서
다른 응용 프로그램을 실행하는데 사용할 수 있는 메모리의 나모지를 남겨두고 파일 캐쉬에서
사용 할 수 있는 메모리의 50%까지 사용한다는 점을 유의 하십시오. 이것이 지속적으로 4M 이하로
떨어진다면 더 많은 메모리의 설치를 심각하게 고려해 봐야 합니다.

1) available Kbytes
- 사용 가능한 메모리 량: 전체 시스템의 메모리 대비 20% 이상

2) Page Faults / sec
- 초당 시스템에서 일어나는 페이지 오류의 초당 평균 수
0에 가까울 수록 좋으며, 2이상의 페이지 오류가 발생하면 메모리 추가를 고려
=> 5초이상 지속되는 하드 페이지 실패는 RAM이 부족하다는 메시지로 중요한 표시입니다.
메모리 장애를 나타내는 다른 카운터로는 Memory:Page input/sec,
Memory:Page reads/sec, Memory:pages/sec 이 있습니다.

3) Page / sec
- 초당 시스템에 의해서 디스크에서 읽거나 디스크로 쓴 페이지 평균값
(5보다 작을 것을 권장(?))

4) cache Fault /sec
- cache fault는 cache manager가 즉각적인 캐쉬에서 페이지를 찾지 못할때 발생

5) process : working set / SQL Server 인스턴스
- SQL 서버가 사용하는 메모리량, 5M 보다 높아야 한다.

6) committed Bytes
- 최고 작업 기간 동안 허용하는 비교치를 특정 시간동안 추적해야 합니다. 적어도
4M의 메모리 또는 커밋된 메모리가 사용할 수 있는 메모리의 5% 이상이 항상 있어야
합니다.

2. CPU 사용량

2.1 Processor

1) % Processor time
CPU 사용율로 75%가 넘지 않을 것을 권장(이후 문제 발생 가능성 높음)

2) % User Time
응용 프로그램이 시용한 CPU 사용률

2.2 System

1) Processor Queue length
프로세서 대기열에 있는 스래드 수 : 2보다 작아야 한다.

2) Context Switches / sec
컴퓨터의 모든 프로세서가 한 스레드에서 다른 스레드로 전환한 횟수.
CPU 당 5000이 넘게 되면, resource Contention Problem 발생

3. Physical Disk
3.1 Physical Disk

1) % Disk Time (Physical % Logical)
- 지속적인 시간동안 55%를 넘지 않아야 한다.
선택한 디스크가 일기 및 스기 요청을 제공하는데 사용되는 경과 시간 비율입니다.
Physical Disk와 함께 Avg. Disk Queue Length는 디스크 드라이브 장애를 나타내는 중요한
표시입니다. 명령줄 유틸리티 diskperf /y 를 실핸한 후에 디스크 카운터를 추격해야 합니다.

2) Avg. Disk Queue Length
- 대기열의 대기수 : 최고 2를 넘지 않을 것을 권장
디스크가 읽기와 스기 요청을 수용할 정도로 빠르지 않으면 해당 요청은 대기열에 넣게 됩니다.
Physical Disk: % Disk Time은 85% 이상이고, avg Disk queue length는 둘 이상이고,
RAM 의 부족으로 디스크 작업이 이루어 질수 없는 경우 디스크에 병목 현상이 발생할 수 있습니다.
Physical Disk에 포함된 디스크 트래픽을 관찰 할수 있는 다른 카운터로 Disk Reads/sec,
Disk writes/sec, SQL Server Log writes/sec 등을 들수 있습니다.

3) Avg. Disk Read Queue Length
- 대기열의 읽기요청 대기수

4) Avg. Disk Write Queue Length
- 대기열의 쓰기 요청 대기수

4. SQL 성능
4.1 SQL Server

1) Cache Manager / Cache Hit Ratio
- 캐쉬 적중률 : 90% 이상 권장(미만 시 메모리 추가, OLTP 시스템에서는 99% 권장)

2) Buffer manager / Buffer Cache Hit Ratio
- 캐쉬 정중률 : 90% 이상 권장

3) Databases / Transactions/sec
- DB에 있는 모든 데이타 파일의 총 크기

4) Buffer manager / Checkpoint pages/sec
- 검사점에 의한 플러쉬된 페이지 수

5) Access Methods / skipped ghosted records/sec
- 고스트된 레코드 수

6) Access Methods / Page Splits/sec
- 페이지 스플릿 발생 수

7) SQL Statistics / SQL Compilations/sec
- 초당 컴파일 수

8) SQL Server General Statistics/User Connection
- 현재 연결된 사용자 수 : Maximum Worker Threads = 255

9) SQL Server : Cache Hit Ratio
- 이것은 SQL 서버가 디스크에 액세스하는 것에 대한 캐쉬에서 데이타를 찾는 시간에
대한 비율입니다. 80%보다 적은 캐쉬 적중률은 SQL Server에 RAM이 부족함을 나타냅니다.
시스템에 RAM이 많이 있다고 해도 SQL Server에 대한 충분한 RAM이 할당되지 않았다면
이러한 문제가 발생할 수 있습니다. SQL 서버에 보다 많은 RAM을 제고하려면 sp_configure
저장된 프로시저 및 SQL Server Enterprise Manager를 사용하십시오.

5. 기타

1) Active server Page, Requests Queued
- 이것은 대기열에서 서비스를 기다리는 요청수를 모니터링합니다.
스트레스 상황에서 지연된 요청수가 상당히 증가할 경우 프로세서 사용율은 비교적 낮게 남아있고,
이것은 스크립트가 처리할수 있는 것보다 많은 호출을 수신하는 COM 개체를 호출하고 있다느 표시입니다.
이러한 경우에 ASP에서 호출된 COM 개체는 일반적으로 장애가 됩니다.

2) System : >% Total Processor Time
- 이것은 프로세서가 사용 중인 시간에 대한 비율입니다. 이 카운터가 지속적으로 80% ~ 100% 사이에서
실행되고 있을때, CPU 병목 현상의 중요한 표시가 됩니다. 이때는 프로세서 추가 설치를 고려해 보십시오.

3) System : Processor Queue Length
- 이것은 프로세서 주기를 기다리며 대기하는 스레드 수의 순간적인 계산(평균 아님)입니다.
둘 이상으로 지속되는 프로세서 대기열 길이는 일반적으로 프로세서 정체를 나타냅니다.
보다 많은 프로세서의 설치를 고려하십시오.

4) SQLServer - Locks : Total Blocking Locks.
- 차단 잠금 수가 높으면 데이터 베이스에서 핫스폿을 나타냅니다.

5) Process : Private Bytes.
- 이 프로세스가 할당한 현재 바이트 수는 다른 프로세스와 공유할수 없습니다.
시스템이 특정 시간동안 성능이 떨어지는 경우에 이 카운터는 메모리 누출의 좋은 표시가 될 수 있습니다.

6) Thread : Context Switches / sec : Inetingo => Thread#
- 프로세서 당 스레트 또는 스레드 출의 최대 수를 측정합니다. 너무 많은 컨텍스트 전환을 하지 않았는지
확인 하려면 이 카운터를 모니터링 해야 합니다. 컨텍스트 전환에 대해서는 심각하게 고려해야 합니다.