웹서버 용량 증설 계획 및 성능 측정이 필요한 경우 아래 항목을 유심히 살펴 보고 로그를 통해서 모니터링하여 판단 할 수 있는
근거 데이터로 활용 할 경우 유용하겠다.
아래 내용하고 비슷한 참고 사이트 주소 : http://tiger5net.egloos.com/5096569
더보기
1. 메모리 사용량
Memory: Available Kbytes
사용 가능한 메모리량: 5000KB 이상 권장
Memory: Page Faults / Sec
초당 시스템에서 일어나는 페이지 오류의 평균적인 수
0에 가까울수록 좋다.
초당 2 이상의 페이지 오류가 발생하면 메모리를 추가해야 한다.
Memory: Pages / Sec
초당 시스템에 의해 디스크에서 읽거나 디스크로 쓴 페이지 평균값
5보다 작을 것을 권장함.
Memory: Cache Fault / Sec
Cache Fault는 Cache Manager가 즉각적인 캐시에서 페이지를 찾지 못할 때 발생
Process : Working Set / SQL Server 인스턴스
SQL 서버가 사용하는 메모리량: 5MB 보다 높아야 한다.
2. CPU 사용량
Processor: %Processor Time
CPU 사용율: 75%가 넘지 않아야 한다. (지수증가)
Processor: %User Time
응용프로그램이 사용한 CPU 사용률
System: Processor Queue length
프로세서 대기열에 있는 스레드 수: 2보다 작아야 한다.
System: Context Switches / Sec
컴퓨터의 모든 프로세서가 한 스레드에서 다른 스레드로 전환한 전체 횟수
CPU 당 5000 이 넘게 되면 Resource Contention Problem.
3. Physical Disk
Physical Disk: %Disk Time (Physical % Logical)
지속적인 시간 동안 55%를 넘지 않아야 한다.
Physical Disk: Avg. Disk Queue Length
대기열의 대기수: 최고 2를 넘지 않을 것을 권장.
Physical Disk: Avg. Disk Read Queue Length
대기열의 읽기요청 대기수
Physical Disk: Avg. Disk Write Queue Length
대기열의 쓰기요청 대기수
4. SQL 성능
SQL Server: Cache Manager / Cache Hit Ratio
캐쉬 적중률:90% 이상 권장 (미만시 메모리 추가, OLTP 시스템에서는 99% 권장)
SQL Server: Buffer Manager / Buffer Cache Hit Ratio
캐쉬 적중률:90% 이상 권장
SQLServer: Databases / Transactions/sec
데이터베이스에있는 모든 데이터 파일의 총 크기
SQLServer: Buffer Manager / Checkpoint pages/sec
검사점에의한 플러시된 페이지수
SQLServer: Access Methods / Skipped Ghosted Records/sec
고스트 레코드수
SQLServer: Access Methods / Page Splits/sec
페이지 스플릿 발생횟수
SQLServer: SQL Statistics / SQL Compilations/sec
초당 컴파일수
SQL Server General Statistics / User Connections
현재 연결된 사용자수: Maximum Worker Threads =255
다음은 계속적으로 모니터링하는 일반적인 성능 카운터입니다. 특정한 값이 한계에 도달하거나 유지되는 것을 관리자에게 알리도록 경보/경고를 설정할 수 있습니다.
Active Server Page, Requests Queued
이것은 대기열에서 서비스를 기다리는 요청 수를 모니터링합니다. 스트레스 상황에서 지연된 요청 수가 상당히 증가할 경우 프로세서 사용률은 비교적 낮게 남아있고 이것은 스크립트가 처리할 수 있는 것보다 많은 호출을 수신하는 COM 개체를 호출하고 있다는 표시입니다. 이러한 경우에 ASP에서 호출된 COM 개체는 일반적으로 장애가 됩니다. 사이트 개발자에게 알려주십시오.
Memory: Page Faults/sec.
5초 이상 지속되는 하드 페이지 실패는 RAM이 부족하다는 메시지로 중요한 표시입니다. 메모리 장애를 나타내는 다른 카운터로 Memory:Pages Input/sec, Memory:Page Reads/sec 및 Memory:Pages/sec을 들 수 있습니다.
Memory: .
시스템 운영에서 사용 가능한 실제 총 메모리를 측정하고 서버에서 모든 프로세스와 응용 프로그램을 실행하는데 필요한 메모리와 비교하십시오. 적어도 최고 사용 상태에서 사용할 수 있는 메모리의 10%를 유지하십시오. 기본적으로 IIS 5.0은 서버 컴퓨터에서 다른 응용 프로그램을 실행하는데 사용할 수 있는 메모리의 나머지를 남겨두고 파일 캐시에서 사용할 수 있는 메모리의 50%까지 사용한다는 점을 유의하십시오. 이것이 지속적으로 4MB 이하로 떨어지면 더 많은 메모리의 설치를 심각하게 고려해봐야 합니다.
Memory: Committed Bytes.
최고 작업 기간 동안 허용하는 비교치를 특정 시간 동안 추적해야 합니다. 적어도 4MB의 메모리 또는 커밋된 메모리가 사용할 수 있는 메모리의 5% 이상이 항상 있어야 합니다.
SQLServer: Cache Hit Ratio.
이것은 SQL 서버가 디스크에 액세스하는 것에 대한 캐시에서 데이터를 찾는 시간에 대한 비율입니다. 80%보다 적은 캐시 적중률은 SQL Server에 RAM이 부족함을 나타냅니다. 시스템에 RAM이 많이 있다고 해도 SQL Server에 충분한 RAM이 할당되지 않았다면 이러한 문제가 발생할 수 있습니다. SQL Server에 보다 많은 RAM을 제공하려면 sp_configure 저장된 프로시저 및 SQL Server Enterprise Manager(Sqlew.exe)를 사용하십시오.
Physical Disk: >% Disk Time.
선택한 디스크가 읽기 및 쓰기 요청을 제공하는데 사용되는 경과 시간 비율입니다. Physical Disk와 함께 Avg. Disk Queue Length는 디스크 드라이브 장애를 나타내는 중요한 표시입니다. 명령줄 유틸리티 Diskperf ?y를 실행한 후에 디스크 카운터를 추적해야 합니다.
Physical Disk: Avg. Disk Queue Length.
디스크가 읽기와 쓰기 요청을 수용할 정도로 빠르지 않으면 해당 요청은 대기열에 넣게 됩니다. Physical Disk: % Disk Time은 85% 이상이고, Avg. Disk Queue Length는 둘 이상이고, RAM의 부족으로 디스크 작업이 이루어질 수 없는 경우 디스크에 병목 현상이 발생할 수 있습니다. Physical Disk에 포함된 디스크 트래픽을 관찰할 수 있는 다른 카운터로 Disk Reads/sec, Physical Disk, Disk Writes/sec, and SQLServer, Log Writes/sec 등을 들 수 있습니다.
RAID 시스템과 같은 디스크 시스템에 보다 많은 물리적 드라이브의 추가를 고려해보십시오. 이것은 읽고 쓸 수 있는 스핀들 수뿐만 아니라 데이터 전송률 속도도 향상시켜 줍니다.
System: >% Total Processor Time.
이것은 프로세서가 사용 중인 시간에 대한 비율입니다. 이 카운터가 지속적으로 80%와 100% 사이에서 실행되고 있을 때 CPU 병목 현상의 중요한 표시가 됩니다. 보다 많은 프로세서의 설치를 고려하십시오.
System: Processor Queue Length.
이것은 프로세서 주기를 기다리며 대기하는 스레드 수의 순간적인(평균이 아닌) 계산입니다. 둘 이상으로 지속되는 프로세서 대기열 길이는 일반적으로 프로세서 정체를 나타냅니다. 보다 많은 프로세서의 설치를 고려하십시오.
SQLServer -Locks: Total Blocking Locks.
차단 잠금 수가 높으면 데이터베이스에서 핫스폿을 나타냅니다. 사이트 개발자에게 알려주십시오.
Process: Private Bytes.
이 프로세스가 할당한 현재 바이트 수는 다른 프로세스와 공유할 수 없습니다. 시스템이 특정 시간 동안 성능이 떨어지는 경우에 이 카운터는 메모리 누출의 좋은 표시가 될 수 있습니다. 사이트 개발자에게 알려주십시오.
Thread: Context Switches: sec: Inetinfo =>Thread#.
프로세서 당 스레드 또는 스레드 풀의 최대 수를 측정합니다. 너무 많은 컨텍스트 전환을 하지 않았는지 확인하려면 이 카운터를 모니터링해야 합니다. 컨텍스트 전환에서 손실한 메모리는 성능이 향상되기 보다는 감소하는 위치에 추가되는 스레드의 이점을 허용합니다. 초 당 15,000개 이상의 컨텍스트 전환에 대해서는 심각하게 고려해야 합니다.
<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><?xml:namespace prefix = o /><?xml:namespace prefix = o /><?xml:namespace prefix = o /><?xml:namespace prefix = o />
시스템 모니터 시 사용되는 대표적인 개체를 몇 가지 정리했습니다.
Processor 개체
1. % PROCESS Time : 프로세서가 스레드를 실행하는 시간의 백분율, 이 값은 100%에서 유휴프로세서의 비율을 빼서 계산된다.
2. % Privileged Time : 프로세서가 특권모드 (운영체제 기능을 수행하고 드라이버를 실행하는 모드)에서 작업한 시간의 백분율. 이 값이 높으면 I/O처리를 위해 시스템 인터럽트가 많이 발생하고 있음을 의미하므로, interrupts/sec카운터를 monitoring해야 한다.
3. % User Time : 프로세서가 사용자 모드에서 작업한 시간의 백분율. 이러한 작업 형태는 응용 프로그램에 의해 발생된다. 일반적으로 % User Time값을 최대화하고 % privileged Time 값은 최소화하는 것이 바람직하다.
4. % Interupt Time : 프로세스가 하드웨어 인터럽트를 처리하는 데 소비된 시간의 백분율, 이러한 interupt는 os 동작의 일부로 간주한다.
5. interrupts/sec : 프로세스가 받아서 처리한 초당 하드웨어 인터럽트 수 ,과도한 인터럽터가 발생하면 PhysicalDisk의 객체카운터를 monitoring할 것, (PhysicalDisk의 문제라면 최신의 디스크 컨트롤러 드라이버를 가지고 IO 대역폭을 늘림으로써 과도한 인터럽트를 줄일수 있다.)
SYSTEM 개체
1. Processor Queue Length : 이 카운터는 프로세서를 얻기 위해 큐에서 대기하는 쓰레드 수를 나타낸다. 다. 즉 실행되기 위해 대기하고 있는 스레드 수를 나타내는 것이다. 시스템에 다중 프로세서를 가지고 있다해도 모든 스레드는 프로세서 시간을 얻기위해 대기하는 하나의 큐만을 가진다. 이 카운터는 실행준비가 되었지만 대기하는 스레드만을 계산하며 현재 실행되고 있는 스레드는 계산하지 않는다. Processor Queue Length 값이 프로세서 당 2보다 크면 cpu 병목을 가지고 있는 것이므로, 더 많은 프로세서를 추가하거나 더 빠른 프로세서로 교체 또는 시스템의 작업 부하를 줄임으로써 이러한 조건을 완화시킬수 있다. 또한 쿼리 튜닝이나 인덱스 전략 또한 해결 책 중에 하나이다.
2. Context Switches /sec : 컨텍스트 전환은 프로세서에서 운영체제나 응용 프로그램이 하나의 스레드를 실행하다가 강제적으로 다른 스레드의 실행으로 전환될 때 발생한다. 멀티 스레드 응용 프로그램을 실행하는 다중 프로세서 시스템에서는 항상 어느 정도의 컨텍스트 전환을 보게 될 것이지만, 초당10,000이상의 컨텍스트 전환이 발생하면 주의하여야 한다.
SQL server : Buffer Manager 개체
1. Buffer Cache Hit Ratio : 현재 버퍼 캐시에 위치한 페이지에서 참조한 요청의 백분율. 페이지가 이미 메모리(버퍼 캐시 내부)에 있으면 SQL server는 디스크 서버시스템에서 읽어오기 위해 물리적 I/O를 요청할 필요가 없다. 물리적 I/O에 비교하면 메모리 I/O는 상대적으로 적게 발생하기 때문에, 높은buffer cache hit ratio는 시스템 성능과 처리량 증가와 관련된다. 잘 튜닝된 시스템은 90% 이상의 값을 가진다. Buffer cache hit ratio 값이 작으면 sql server에 더 많은 메모리를 할당하도록 한다. 모든 현재 메모리가 이미 sql server에 할당 되었다면 시스템의 물리적 메모리 양을 늘려야 한다.
2. Procedure cache Pages : 컴파일된 쿼리와 저장 프로시저를 저장하기 위해 Sql Server에 의해 사용된 페이지 수. 이 수에 8kb를 곱하면 사용중인 양을 Kb로 알수 있다.
3. Free Pages : 할당되지 않은 sql server 메모리 버퍼수 (8kb 페이지로). 이 값이 지속적으로 작거나 0이면 서버에 메모리가 작음을 나타내는 것이다. 이 상황을 완화하려면 메모리 할당을 증가시키거나 물리적으로 메모리를 추가시켜야 한다.
4. Page Reads/sec : Sql server에서 발급한 초당 물리적 데이터베이스 페이지의 읽기 요청 횟수. 시스템이 안정상태에 이를 때까지 page reads/sec카운터 값이 높은 것을 볼 수 있다. 그러나 많은페이지가 메모리에 읽혀져 캐시 히트로 다시 액세스된다면 페이지 읽기 수는 감소하게 된다. 이 값이 지속적으로 높게 유지되면 sql server의 메모리 할당을 증가시키거나, 시스템에 물리적 메모리를 추가하거나 또는 쿼리를 튜닝하여야 한다.
5. Stolen Pages : 이 카운터는 시스템의 다른 응용 프로그램의 요구를 충족시키기 위해 얼마나 많은 8kb 크기 페이지들이 SQL server데이터 캐시로부터 제거되었는지를 나타낸다. Win2k는 이 제거된 메모리를 다른 시스템 구성 요소의 요구조건을 만족시키기 위해 다시 할당하게 된다. Min server memory를 높이는 것이 stolen pages의 카운터의 수를 떨어뜨릴 수 있는 방법이나 이렇게 되면 다른 응용프로그램이 메모리 할당을 받지 못해 전체적으로 시스템이 늦어지는 현상이 발생할 수 있다. 이럴 때의 유일한 해결책은 시스템의 메모리를 추가해야 한다.
6. page Writes / sec : Sql server에 의해 발급된 초당 물리적 데이터베이스 페이지의 쓰기 수
SQLServer : Databases 개체
1. Log Flush Waits/sec : 로그 플러쉬는 로그 버퍼에 있는 데이터가 물리적 로그 파일로 플러쉬될 때 발생한다. 즉 로그 플러쉬를 대기하는 데이터베이스 커밋 수를 말하는 것이다. 데이터베이스 페이지의 무결성을 유지하기 위해 변경된 데이터 페이지는 로그버퍼가 디스크에 flush될 때까지 데이터 파일 디스크로 기록될 수 없다. 즉 로그버퍼가 로그 파일에 플러쉬 되어야 트랜잭션은 커밋될 수 있고 dirty page도 테이터 디스크에 기록될 수 있다. 커밋이 로그 플러쉬를 기다릴 때 로그 디바이스에는 일반적으로 병목이 발생하는데, 로그 디바이스의 I/O 대역폭을 늘림으로써 이 조건은 쉽게 치료할 수 있다. (로그 파일을 위해 사용되는 컨트롤러의 쓰기 캐시를 활성화 시키거나 로그 파일이 존재하는 디스크 드라이버의 속도를 늘릴 수 있다)
2. Percent Log Used : Sql server가 사용하고 있는 현재 정의된 로그 공간의 퍼센트. 이 카운터 차트는 로그 파일이 얼마나 빨리 증가하는지 언제 파일이 짤려졌는지(로그 백업 명령의 결과로 나타날 수 있으며, 백업이 완료되면 로그를 잘라낸다)를 보여준다.
SqlServer : General Statistics 개체
1. user connections : Sql Server로의 현재 사용자 연결 수. 정기적으로 이 카운터를 모니터링하면 사용자 동작에 있어서의 경향을 파악할 수 있고(이를 테면 사업 성장) 사용자 연결이 어떤 비율로 증가하였는지를 알 수 있다.
SQLSEVER:Latches 개체
Latch는 트랜잭션 도안 잠금을 걸 필요가 없는 동작을 보호하는 단기간의 동기화 개체이다. 관계 엔진(Relational Engine)은 쿼리를 처리할 때, 베이스 테이블이나 인덱스로부터 행이 필요할 때마다 스토리지 엔진에 행을 반환하도록 요청한다. 스토리지 엔진이 행을 Db엔진에 전송할 때 스토리지 엔진은 읽혀지는 행의 위치를 나타내는 페이지 오프셋 테이블 엔트리와 같은 행의 내용이나 페이지 구조가 변경되지 않도록 유지해야 한다. 이러한 동작은 래치를 획득하고 메모리의 행으 관계 엔진에 전송하고 나서 래치를 해체함으로써 수행된다.
래치수가 많다는 것은 낮은 cache hit ratio로 인한 디스크 IO의 증가, 디스크의 병목을 초래하게 된다. 이 현상의 해결책 역시 쿼리 튜닝, 메모리 증가, 시스템 IO 대역폭 증가로 해결해야 한다.
1. Average Latch Wait Time(ms) : 요청된 래치에 대한 평균 래치 대기 시간
2. Latch Waits/Sec : 래치의 요청수
SqlServer:Lock 개체
1. Average Wait Time(ms) : 잠금이 대기하였던 평균 시간을 밀리초 단위로 나타냄
2. Lock Timeout /sec : 잠금을 얻기 위해 대기하면서 타임 아웃된 잠금 요청 횟수
3. Lock Waits/sec : 즉시 충족시킬 수 없고 잠금을 허가하기 위해서 호출자를 기다려야 하는 잠금 요청 횟수
4. Number of DeadLocks / sec : 교착상태를 일으킨 잠금수
데이터 베이스에서 Lock 메커니즘은 모든 쿼리와 데이터 액세스에 대해 데이터 무결성을 보장하며, 각각은 데이터 행 수준, 페이지 수준, 테이블 수준 또는 데이터베이스 수준으로 얻어질 수 있다. Lock 메커니즘은 응용프로그램과 쿼리가 어떻게 동작하고 공존하는지 또는 개별성과 동시성을 제공하기 위한 것이다. 체크해야할 중요한 카운터는Number of DeadLocks / sec 이다.
DeadLock 시점에서의 해결은 victim을 선택해야 하는 것이며 장기적인 해결을 하기 위한 접근은 아래와 같다. (또는 Set Daedlock_priority Low문을 사용하면 그 트랜잭션이 교착 상태 발생시 kill이 된다.)
1. 동일한 순서로 개체에 액세스한다.
2. 트랜잭션내에서 사용자 동작을 피한다.
3. 트랜잭션을 하나의 배치로 짧게 유지한다.
4. 가능한 낮은 격리 수준(Isolation level)을 사용한다. : Serializable < Read Committed
SQLServer:Memory Manager 개체
Memory Manager 개체는 Sql server가 할당된 메모리를 관리하는 방법에 대한 유용한 데이터를 제공한다. 각 프로세스는 데이터베이스에서 실행되기 때문에 메모리 자원을 요청하고 부여받는데, memory grants pending 카운터를 모니터링하면 얼마나 많은 사용자나 프로세스가 메모리 허가를 기다리고 있는지 알수 있다. Sql memory가 부족하면 더 많은 사용자나 프로세스가 메모리를 대기하게 되므로 Memory grants Pending값이 증가하게 된다.
1. Memory Grants Pending : 작업 공간 메모리 허가를 위해 대기하고 있는 현재의 프로세스 수
2. Target Server Memory(kb) : sql Server가 사용할 수 있는 전체 메모리 양
3. Total Server Memory(kb) : Sql Server가 사용하고 있는 전체 메모리 양
SQLServer:SQL statistics 개체
1. Batch Request/sec : 서버가 받은 SQL 배치 요청 수
2. Sql Compilations/Sec : 초당 SQL Server가 SQL 문을 컴파일하는 수
3. SQL Re-Compilations/sec : 초당 SQL Server가 수행하는 SQL문의 재컴파일 수
Memory
Mssql 은 기본적으로 swap의 과정(ram <-> virtual memory간의 paging)을 하지 않는다. Ram, cache object를 사용하는 것으로 한다.
1. page faults / sec : 초당 프로세서에 의해 처리된 페이지 없음 오류 수. 하드페이지폴트(디스크 액세스를 요구함)와 소프트 페이지 폴트(페이지를 물리 메모리 내에서 찾음)를 포함
2. Page Reads/sec : 하드 페이지 폴트를 해결하기 위해 디스크로부터 읽어온 횟수
3. Page Writes/sec : 물리적 메모리 공간을 해제하기 위해 페이지가 디스크에 쓰연 횟수
4. Pages/sec : 하드 페이지 폴트를 해결하기 위해 디스크로부터 읽거나 쓴 페이지 수 이것은 (read + Write 카운터의 합)
포함해야할 자료
http://www.microsoft.com/korea/technet/iis/prfrelmn.mspx
웹서버 용량 증설 계획 및 성능 측정이 필요한 경우 아래 항목을 유심히 살펴 보고 로그를 통해서 모니터링하여 판단 할 수 있는
근거 데이터로 활용 할 경우 유용하겠다.
아래 내용하고 비슷한 참고 사이트 주소 : http://tiger5net.egloos.com/5096569
더보기
1. 메모리 사용량
Memory: Available Kbytes
사용 가능한 메모리량: 5000KB 이상 권장
Memory: Page Faults / Sec
초당 시스템에서 일어나는 페이지 오류의 평균적인 수
0에 가까울수록 좋다.
초당 2 이상의 페이지 오류가 발생하면 메모리를 추가해야 한다.
Memory: Pages / Sec
초당 시스템에 의해 디스크에서 읽거나 디스크로 쓴 페이지 평균값
5보다 작을 것을 권장함.
Memory: Cache Fault / Sec
Cache Fault는 Cache Manager가 즉각적인 캐시에서 페이지를 찾지 못할 때 발생
Process : Working Set / SQL Server 인스턴스
SQL 서버가 사용하는 메모리량: 5MB 보다 높아야 한다.
2. CPU 사용량
Processor: %Processor Time
CPU 사용율: 75%가 넘지 않아야 한다. (지수증가)
Processor: %User Time
응용프로그램이 사용한 CPU 사용률
System: Processor Queue length
프로세서 대기열에 있는 스레드 수: 2보다 작아야 한다.
System: Context Switches / Sec
컴퓨터의 모든 프로세서가 한 스레드에서 다른 스레드로 전환한 전체 횟수
CPU 당 5000 이 넘게 되면 Resource Contention Problem.
3. Physical Disk
Physical Disk: %Disk Time (Physical % Logical)
지속적인 시간 동안 55%를 넘지 않아야 한다.
Physical Disk: Avg. Disk Queue Length
대기열의 대기수: 최고 2를 넘지 않을 것을 권장.
Physical Disk: Avg. Disk Read Queue Length
대기열의 읽기요청 대기수
Physical Disk: Avg. Disk Write Queue Length
대기열의 쓰기요청 대기수
4. SQL 성능
SQL Server: Cache Manager / Cache Hit Ratio
캐쉬 적중률:90% 이상 권장 (미만시 메모리 추가, OLTP 시스템에서는 99% 권장)
SQL Server: Buffer Manager / Buffer Cache Hit Ratio
캐쉬 적중률:90% 이상 권장
SQLServer: Databases / Transactions/sec
데이터베이스에있는 모든 데이터 파일의 총 크기
SQLServer: Buffer Manager / Checkpoint pages/sec
검사점에의한 플러시된 페이지수
SQLServer: Access Methods / Skipped Ghosted Records/sec
고스트 레코드수
SQLServer: Access Methods / Page Splits/sec
페이지 스플릿 발생횟수
SQLServer: SQL Statistics / SQL Compilations/sec
초당 컴파일수
SQL Server General Statistics / User Connections
현재 연결된 사용자수: Maximum Worker Threads =255
다음은 계속적으로 모니터링하는 일반적인 성능 카운터입니다. 특정한 값이 한계에 도달하거나 유지되는 것을 관리자에게 알리도록 경보/경고를 설정할 수 있습니다.
Active Server Page, Requests Queued
이것은 대기열에서 서비스를 기다리는 요청 수를 모니터링합니다. 스트레스 상황에서 지연된 요청 수가 상당히 증가할 경우 프로세서 사용률은 비교적 낮게 남아있고 이것은 스크립트가 처리할 수 있는 것보다 많은 호출을 수신하는 COM 개체를 호출하고 있다는 표시입니다. 이러한 경우에 ASP에서 호출된 COM 개체는 일반적으로 장애가 됩니다. 사이트 개발자에게 알려주십시오.
Memory: Page Faults/sec.
5초 이상 지속되는 하드 페이지 실패는 RAM이 부족하다는 메시지로 중요한 표시입니다. 메모리 장애를 나타내는 다른 카운터로 Memory:Pages Input/sec, Memory:Page Reads/sec 및 Memory:Pages/sec을 들 수 있습니다.
Memory: .
시스템 운영에서 사용 가능한 실제 총 메모리를 측정하고 서버에서 모든 프로세스와 응용 프로그램을 실행하는데 필요한 메모리와 비교하십시오. 적어도 최고 사용 상태에서 사용할 수 있는 메모리의 10%를 유지하십시오. 기본적으로 IIS 5.0은 서버 컴퓨터에서 다른 응용 프로그램을 실행하는데 사용할 수 있는 메모리의 나머지를 남겨두고 파일 캐시에서 사용할 수 있는 메모리의 50%까지 사용한다는 점을 유의하십시오. 이것이 지속적으로 4MB 이하로 떨어지면 더 많은 메모리의 설치를 심각하게 고려해봐야 합니다.
Memory: Committed Bytes.
최고 작업 기간 동안 허용하는 비교치를 특정 시간 동안 추적해야 합니다. 적어도 4MB의 메모리 또는 커밋된 메모리가 사용할 수 있는 메모리의 5% 이상이 항상 있어야 합니다.
SQLServer: Cache Hit Ratio.
이것은 SQL 서버가 디스크에 액세스하는 것에 대한 캐시에서 데이터를 찾는 시간에 대한 비율입니다. 80%보다 적은 캐시 적중률은 SQL Server에 RAM이 부족함을 나타냅니다. 시스템에 RAM이 많이 있다고 해도 SQL Server에 충분한 RAM이 할당되지 않았다면 이러한 문제가 발생할 수 있습니다. SQL Server에 보다 많은 RAM을 제공하려면 sp_configure 저장된 프로시저 및 SQL Server Enterprise Manager(Sqlew.exe)를 사용하십시오.
Physical Disk: >% Disk Time.
선택한 디스크가 읽기 및 쓰기 요청을 제공하는데 사용되는 경과 시간 비율입니다. Physical Disk와 함께 Avg. Disk Queue Length는 디스크 드라이브 장애를 나타내는 중요한 표시입니다. 명령줄 유틸리티 Diskperf ?y를 실행한 후에 디스크 카운터를 추적해야 합니다.
Physical Disk: Avg. Disk Queue Length.
디스크가 읽기와 쓰기 요청을 수용할 정도로 빠르지 않으면 해당 요청은 대기열에 넣게 됩니다. Physical Disk: % Disk Time은 85% 이상이고, Avg. Disk Queue Length는 둘 이상이고, RAM의 부족으로 디스크 작업이 이루어질 수 없는 경우 디스크에 병목 현상이 발생할 수 있습니다. Physical Disk에 포함된 디스크 트래픽을 관찰할 수 있는 다른 카운터로 Disk Reads/sec, Physical Disk, Disk Writes/sec, and SQLServer, Log Writes/sec 등을 들 수 있습니다.
RAID 시스템과 같은 디스크 시스템에 보다 많은 물리적 드라이브의 추가를 고려해보십시오. 이것은 읽고 쓸 수 있는 스핀들 수뿐만 아니라 데이터 전송률 속도도 향상시켜 줍니다.
System: >% Total Processor Time.
이것은 프로세서가 사용 중인 시간에 대한 비율입니다. 이 카운터가 지속적으로 80%와 100% 사이에서 실행되고 있을 때 CPU 병목 현상의 중요한 표시가 됩니다. 보다 많은 프로세서의 설치를 고려하십시오.
System: Processor Queue Length.
이것은 프로세서 주기를 기다리며 대기하는 스레드 수의 순간적인(평균이 아닌) 계산입니다. 둘 이상으로 지속되는 프로세서 대기열 길이는 일반적으로 프로세서 정체를 나타냅니다. 보다 많은 프로세서의 설치를 고려하십시오.
SQLServer -Locks: Total Blocking Locks.
차단 잠금 수가 높으면 데이터베이스에서 핫스폿을 나타냅니다. 사이트 개발자에게 알려주십시오.
Process: Private Bytes.
이 프로세스가 할당한 현재 바이트 수는 다른 프로세스와 공유할 수 없습니다. 시스템이 특정 시간 동안 성능이 떨어지는 경우에 이 카운터는 메모리 누출의 좋은 표시가 될 수 있습니다. 사이트 개발자에게 알려주십시오.
Thread: Context Switches: sec: Inetinfo =>Thread#.
프로세서 당 스레드 또는 스레드 풀의 최대 수를 측정합니다. 너무 많은 컨텍스트 전환을 하지 않았는지 확인하려면 이 카운터를 모니터링해야 합니다. 컨텍스트 전환에서 손실한 메모리는 성능이 향상되기 보다는 감소하는 위치에 추가되는 스레드의 이점을 허용합니다. 초 당 15,000개 이상의 컨텍스트 전환에 대해서는 심각하게 고려해야 합니다.
<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><?xml:namespace prefix = o /><?xml:namespace prefix = o /><?xml:namespace prefix = o /><?xml:namespace prefix = o />
시스템 모니터 시 사용되는 대표적인 개체를 몇 가지 정리했습니다.
Processor 개체
1. % PROCESS Time : 프로세서가 스레드를 실행하는 시간의 백분율, 이 값은 100%에서 유휴프로세서의 비율을 빼서 계산된다.
2. % Privileged Time : 프로세서가 특권모드 (운영체제 기능을 수행하고 드라이버를 실행하는 모드)에서 작업한 시간의 백분율. 이 값이 높으면 I/O처리를 위해 시스템 인터럽트가 많이 발생하고 있음을 의미하므로, interrupts/sec카운터를 monitoring해야 한다.
3. % User Time : 프로세서가 사용자 모드에서 작업한 시간의 백분율. 이러한 작업 형태는 응용 프로그램에 의해 발생된다. 일반적으로 % User Time값을 최대화하고 % privileged Time 값은 최소화하는 것이 바람직하다.
4. % Interupt Time : 프로세스가 하드웨어 인터럽트를 처리하는 데 소비된 시간의 백분율, 이러한 interupt는 os 동작의 일부로 간주한다.
5. interrupts/sec : 프로세스가 받아서 처리한 초당 하드웨어 인터럽트 수 ,과도한 인터럽터가 발생하면 PhysicalDisk의 객체카운터를 monitoring할 것, (PhysicalDisk의 문제라면 최신의 디스크 컨트롤러 드라이버를 가지고 IO 대역폭을 늘림으로써 과도한 인터럽트를 줄일수 있다.)
SYSTEM 개체
1. Processor Queue Length : 이 카운터는 프로세서를 얻기 위해 큐에서 대기하는 쓰레드 수를 나타낸다. 다. 즉 실행되기 위해 대기하고 있는 스레드 수를 나타내는 것이다. 시스템에 다중 프로세서를 가지고 있다해도 모든 스레드는 프로세서 시간을 얻기위해 대기하는 하나의 큐만을 가진다. 이 카운터는 실행준비가 되었지만 대기하는 스레드만을 계산하며 현재 실행되고 있는 스레드는 계산하지 않는다. Processor Queue Length 값이 프로세서 당 2보다 크면 cpu 병목을 가지고 있는 것이므로, 더 많은 프로세서를 추가하거나 더 빠른 프로세서로 교체 또는 시스템의 작업 부하를 줄임으로써 이러한 조건을 완화시킬수 있다. 또한 쿼리 튜닝이나 인덱스 전략 또한 해결 책 중에 하나이다.
2. Context Switches /sec : 컨텍스트 전환은 프로세서에서 운영체제나 응용 프로그램이 하나의 스레드를 실행하다가 강제적으로 다른 스레드의 실행으로 전환될 때 발생한다. 멀티 스레드 응용 프로그램을 실행하는 다중 프로세서 시스템에서는 항상 어느 정도의 컨텍스트 전환을 보게 될 것이지만, 초당10,000이상의 컨텍스트 전환이 발생하면 주의하여야 한다.
SQL server : Buffer Manager 개체
1. Buffer Cache Hit Ratio : 현재 버퍼 캐시에 위치한 페이지에서 참조한 요청의 백분율. 페이지가 이미 메모리(버퍼 캐시 내부)에 있으면 SQL server는 디스크 서버시스템에서 읽어오기 위해 물리적 I/O를 요청할 필요가 없다. 물리적 I/O에 비교하면 메모리 I/O는 상대적으로 적게 발생하기 때문에, 높은buffer cache hit ratio는 시스템 성능과 처리량 증가와 관련된다. 잘 튜닝된 시스템은 90% 이상의 값을 가진다. Buffer cache hit ratio 값이 작으면 sql server에 더 많은 메모리를 할당하도록 한다. 모든 현재 메모리가 이미 sql server에 할당 되었다면 시스템의 물리적 메모리 양을 늘려야 한다.
2. Procedure cache Pages : 컴파일된 쿼리와 저장 프로시저를 저장하기 위해 Sql Server에 의해 사용된 페이지 수. 이 수에 8kb를 곱하면 사용중인 양을 Kb로 알수 있다.
3. Free Pages : 할당되지 않은 sql server 메모리 버퍼수 (8kb 페이지로). 이 값이 지속적으로 작거나 0이면 서버에 메모리가 작음을 나타내는 것이다. 이 상황을 완화하려면 메모리 할당을 증가시키거나 물리적으로 메모리를 추가시켜야 한다.
4. Page Reads/sec : Sql server에서 발급한 초당 물리적 데이터베이스 페이지의 읽기 요청 횟수. 시스템이 안정상태에 이를 때까지 page reads/sec카운터 값이 높은 것을 볼 수 있다. 그러나 많은페이지가 메모리에 읽혀져 캐시 히트로 다시 액세스된다면 페이지 읽기 수는 감소하게 된다. 이 값이 지속적으로 높게 유지되면 sql server의 메모리 할당을 증가시키거나, 시스템에 물리적 메모리를 추가하거나 또는 쿼리를 튜닝하여야 한다.
5. Stolen Pages : 이 카운터는 시스템의 다른 응용 프로그램의 요구를 충족시키기 위해 얼마나 많은 8kb 크기 페이지들이 SQL server데이터 캐시로부터 제거되었는지를 나타낸다. Win2k는 이 제거된 메모리를 다른 시스템 구성 요소의 요구조건을 만족시키기 위해 다시 할당하게 된다. Min server memory를 높이는 것이 stolen pages의 카운터의 수를 떨어뜨릴 수 있는 방법이나 이렇게 되면 다른 응용프로그램이 메모리 할당을 받지 못해 전체적으로 시스템이 늦어지는 현상이 발생할 수 있다. 이럴 때의 유일한 해결책은 시스템의 메모리를 추가해야 한다.
6. page Writes / sec : Sql server에 의해 발급된 초당 물리적 데이터베이스 페이지의 쓰기 수
SQLServer : Databases 개체
1. Log Flush Waits/sec : 로그 플러쉬는 로그 버퍼에 있는 데이터가 물리적 로그 파일로 플러쉬될 때 발생한다. 즉 로그 플러쉬를 대기하는 데이터베이스 커밋 수를 말하는 것이다. 데이터베이스 페이지의 무결성을 유지하기 위해 변경된 데이터 페이지는 로그버퍼가 디스크에 flush될 때까지 데이터 파일 디스크로 기록될 수 없다. 즉 로그버퍼가 로그 파일에 플러쉬 되어야 트랜잭션은 커밋될 수 있고 dirty page도 테이터 디스크에 기록될 수 있다. 커밋이 로그 플러쉬를 기다릴 때 로그 디바이스에는 일반적으로 병목이 발생하는데, 로그 디바이스의 I/O 대역폭을 늘림으로써 이 조건은 쉽게 치료할 수 있다. (로그 파일을 위해 사용되는 컨트롤러의 쓰기 캐시를 활성화 시키거나 로그 파일이 존재하는 디스크 드라이버의 속도를 늘릴 수 있다)
2. Percent Log Used : Sql server가 사용하고 있는 현재 정의된 로그 공간의 퍼센트. 이 카운터 차트는 로그 파일이 얼마나 빨리 증가하는지 언제 파일이 짤려졌는지(로그 백업 명령의 결과로 나타날 수 있으며, 백업이 완료되면 로그를 잘라낸다)를 보여준다.
SqlServer : General Statistics 개체
1. user connections : Sql Server로의 현재 사용자 연결 수. 정기적으로 이 카운터를 모니터링하면 사용자 동작에 있어서의 경향을 파악할 수 있고(이를 테면 사업 성장) 사용자 연결이 어떤 비율로 증가하였는지를 알 수 있다.
SQLSEVER:Latches 개체
Latch는 트랜잭션 도안 잠금을 걸 필요가 없는 동작을 보호하는 단기간의 동기화 개체이다. 관계 엔진(Relational Engine)은 쿼리를 처리할 때, 베이스 테이블이나 인덱스로부터 행이 필요할 때마다 스토리지 엔진에 행을 반환하도록 요청한다. 스토리지 엔진이 행을 Db엔진에 전송할 때 스토리지 엔진은 읽혀지는 행의 위치를 나타내는 페이지 오프셋 테이블 엔트리와 같은 행의 내용이나 페이지 구조가 변경되지 않도록 유지해야 한다. 이러한 동작은 래치를 획득하고 메모리의 행으 관계 엔진에 전송하고 나서 래치를 해체함으로써 수행된다.
래치수가 많다는 것은 낮은 cache hit ratio로 인한 디스크 IO의 증가, 디스크의 병목을 초래하게 된다. 이 현상의 해결책 역시 쿼리 튜닝, 메모리 증가, 시스템 IO 대역폭 증가로 해결해야 한다.
1. Average Latch Wait Time(ms) : 요청된 래치에 대한 평균 래치 대기 시간
2. Latch Waits/Sec : 래치의 요청수
SqlServer:Lock 개체
1. Average Wait Time(ms) : 잠금이 대기하였던 평균 시간을 밀리초 단위로 나타냄
2. Lock Timeout /sec : 잠금을 얻기 위해 대기하면서 타임 아웃된 잠금 요청 횟수
3. Lock Waits/sec : 즉시 충족시킬 수 없고 잠금을 허가하기 위해서 호출자를 기다려야 하는 잠금 요청 횟수
4. Number of DeadLocks / sec : 교착상태를 일으킨 잠금수
데이터 베이스에서 Lock 메커니즘은 모든 쿼리와 데이터 액세스에 대해 데이터 무결성을 보장하며, 각각은 데이터 행 수준, 페이지 수준, 테이블 수준 또는 데이터베이스 수준으로 얻어질 수 있다. Lock 메커니즘은 응용프로그램과 쿼리가 어떻게 동작하고 공존하는지 또는 개별성과 동시성을 제공하기 위한 것이다. 체크해야할 중요한 카운터는Number of DeadLocks / sec 이다.
DeadLock 시점에서의 해결은 victim을 선택해야 하는 것이며 장기적인 해결을 하기 위한 접근은 아래와 같다. (또는 Set Daedlock_priority Low문을 사용하면 그 트랜잭션이 교착 상태 발생시 kill이 된다.)
1. 동일한 순서로 개체에 액세스한다.
2. 트랜잭션내에서 사용자 동작을 피한다.
3. 트랜잭션을 하나의 배치로 짧게 유지한다.
4. 가능한 낮은 격리 수준(Isolation level)을 사용한다. : Serializable < Read Committed
SQLServer:Memory Manager 개체
Memory Manager 개체는 Sql server가 할당된 메모리를 관리하는 방법에 대한 유용한 데이터를 제공한다. 각 프로세스는 데이터베이스에서 실행되기 때문에 메모리 자원을 요청하고 부여받는데, memory grants pending 카운터를 모니터링하면 얼마나 많은 사용자나 프로세스가 메모리 허가를 기다리고 있는지 알수 있다. Sql memory가 부족하면 더 많은 사용자나 프로세스가 메모리를 대기하게 되므로 Memory grants Pending값이 증가하게 된다.
1. Memory Grants Pending : 작업 공간 메모리 허가를 위해 대기하고 있는 현재의 프로세스 수
2. Target Server Memory(kb) : sql Server가 사용할 수 있는 전체 메모리 양
3. Total Server Memory(kb) : Sql Server가 사용하고 있는 전체 메모리 양
SQLServer:SQL statistics 개체
1. Batch Request/sec : 서버가 받은 SQL 배치 요청 수
2. Sql Compilations/Sec : 초당 SQL Server가 SQL 문을 컴파일하는 수
3. SQL Re-Compilations/sec : 초당 SQL Server가 수행하는 SQL문의 재컴파일 수
Memory
Mssql 은 기본적으로 swap의 과정(ram <-> virtual memory간의 paging)을 하지 않는다. Ram, cache object를 사용하는 것으로 한다.
1. page faults / sec : 초당 프로세서에 의해 처리된 페이지 없음 오류 수. 하드페이지폴트(디스크 액세스를 요구함)와 소프트 페이지 폴트(페이지를 물리 메모리 내에서 찾음)를 포함
2. Page Reads/sec : 하드 페이지 폴트를 해결하기 위해 디스크로부터 읽어온 횟수
3. Page Writes/sec : 물리적 메모리 공간을 해제하기 위해 페이지가 디스크에 쓰연 횟수
4. Pages/sec : 하드 페이지 폴트를 해결하기 위해 디스크로부터 읽거나 쓴 페이지 수 이것은 (read + Write 카운터의 합)
포함해야할 자료
http://www.microsoft.com/korea/technet/iis/prfrelmn.mspx
서버성능 측정 시 성능모니터링 카운터 프로그래밍
| 분류 | 항목 | 임계값 | 대처방법 |
| 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 : 서버 성능 평가
Memory\Free System Page Table Entries 시스템에서 현재 사용되지 않는 페이지 테이블 항목의 수를 나타냅니다. 이 숫자가 5,000보다 작으면 메모리 누수가 있을 수 있습니다.
'wif LiNoUz > SERVER' 카테고리의 다른 글
| 성능모니터링 (2) | 2014.01.13 |
|---|---|
| router add 다중 네트워크 (3) | 2013.03.25 |
| 공유기 뚫기 (7) | 2013.03.22 |
| Nonpaged and apged pool error (1) | 2013.02.07 |
| 성능모니터 DB로 쑤셔넣기 (0) | 2013.01.11 |