 성능 및 안정성 모니터링 하드웨어 및 응용 프로그램 모니터링사이트를 운영할 때 중요한 부분 중 하나가 성능과 안정성에 대한 모니터링입니다. 모니터링을 통해 성능 병목이 발생할 가능성이 있는지 파악하고 기준 성능 값을 설정할 수 있습니다. 이 기준값을 사용하면 성능 조정 및 하드웨어 업그레이드의 효과를 평가할 수 있습니다. 안정성을 모니터링하면 서비스가 중단되기 전에 문제를 파악할 수 있습니다. 응용 프로그램에 문제가 발생하여 서비스가 중단될 경우 자동으로 다시 시작하도록 IIS를 설정할 수도 있습니다. 이렇게 다시 시작되는 작동을 모니터링하면 초기 단계에 잘못된 응용 프로그램의 문제를 수정할 수 있습니다. 서버 성능 모니터링 및 테스트 도구Microsoft는 사용자의 성능 조정 및 테스트 요구를 지원하기 위해 여러 가지 도구를 제공합니다. Windows 2000 및 IIS 5.0에 포함된 도구도 있고, Windows 2000 리소스 키트 CD에 포함된 도구도 있고, Microsoft 웹 사이트에서 다운로드할 수 있는 도구도 있습니다.
이러한 도구에서는 IIS 5.0 및 Windows 2000 운영 체제에 내장된 성능 카운터가 중요한 기능을 합니다. 개발자가 작성하는 ISAPI DLLS 또는 COM 구성 요소에 사용자 정의 성능 카운터를 넣을 수도 있습니다. 시스템 모니터, 웹 응용 프로그램 스트레스 도구 및 WCAT를 포함하여 위에서 설명한 여러 가지 도구에서 이 카운터를 바로 읽을 수 있습니다. 시스템 모니터는 웹 서버의 성능 기준을 설정하는 데 가장 중요한 도구로 소프트웨어나 하드웨어에 대한 변경이 성능에 미치는 영향을 모니터링합니다. 시스템 모니터에는 성능 카운터를 모니터링하거나 로깅할 때 값을 확인할 수 있는 UI가 있습니다. 이 UI를 사용하면 그래픽 방식으로 카운터 작동을 로깅하고 이벤트 뷰어에 표시할 경고를 설정할 수 있습니다. 시스템 모니터에는 시스템의 각 카운터에 대한 설명서가 있습니다. 각 도구에 대한 자세한 내용은 Windows 2000 리소스 키트에 포함된 IIS 5.0 온라인 설명서를 참조하십시오.  하드웨어 모니터링메모리메모리 부족으로 문제가 발생했는데 시스템의 다른 부분에 문제가 발생한 것처럼 표시되는 경우가 있습니다. 먼저 서버에 메모리가 충분한지 모니터링한 다음 다른 구성 요소를 확인해야 합니다. Windows 2000 및 IIS 5.0을 실행할 경우 전용 웹 서버에 필요한 최소 RAM 크기는 128MB지만 256MB에서 1GB 정도는 있어야 불편 없이 사용할 수 있습니다. 특히 전자 상거래 사이트, 컨텐트가 많은 사이트, 처리해야 할 트래픽이 많은 사이트 등에서는 메모리를 추가하는 것이 좋습니다. 기본적으로 IIS 파일 캐시가 사용 가능한 메모리의 절반까지 사용하도록 설정되기 때문에 메모리가 많을수록 IIS 파일 캐시가 커집니다. 참고 Windows 2000 Advanced Server는 RAM 크기를 8GB까지 지원하지만 IIS 파일 캐시는 4GB 이하의 메모리만 사용합니다. 현재 설치된 메모리로 서버를 작동할 수 있는지 확인하려면 Windows 2000에 내장된 성능 도구를 사용하십시오. 성능 도구에 포함된 시스템 모니터에 시간에 따라 변하는 카운터 값이 그래픽 방식으로 표시됩니다. 캐시 설정을 계속 확인하십시오. 메모리를 추가하는 것만으로 반드시 성능 문제가 해결되지는 않습니다. IIS 캐시 설정과 이 설정이 서버의 성능에 어떠한 영향을 미치는지 알아야 합니다. 이 설정이 서버의 부하에 맞지 않을 경우 메모리 부족보다는 이 설정 때문에 성능 병목이 발생할 수 있습니다. 이 캐시 설정에 대한 자세한 내용은 이 문서의 IIS 설정 단락과 부록 1: 성능 설정을 참조하십시오. ASP 및 IIS의 캐싱에 대한 자세한 내용은 부록 3: ASP 캐싱을 참조하십시오. 참고 성능 카운터를 사용하여 성능을 모니터링할 때 카운터 추가 대화상자에서 해당 카운터를 선택하고 설명을 누르면 카운터에 대한 설명을 볼 수 있습니다. 메모리와 관련된 성능 병목이 있는지 확인하려면 다음 카운터를 로깅하십시오.
RAM을 추가하는 것 외에도 다음과 같은 방법을 사용하여 성능을 향상시킬 수 있습니다: 데이터 구성 향상, 디스크 미러링 또는 스트라이핑, CGI 응용 프로그램을 ISAPI 또는 ASP 응용 프로그램으로 교체, 페이징 파일 확대, IIS 파일 캐시 시간 재설정, 불필요한 기능 제거, 파일 시스템 캐시의 균형을 IIS 5.0 작동 세트로 변경. 마지막 방법은 나중에 자세하게 설명합니다. 프로세서 용량사용자는 웹 사이트의 빠른 응답을 원하고 동적으로 생성되는 컨텐트의 양이 증가하고 있으므로 빠르고 효율적인 프로세서를 사용하는 것이 중요합니다. 하나 이상의 프로세스가 프로세서 시간의 대부분을 사용할 경우에 병목이 발생합니다. 그러면 실행 준비된 프로세스 스레드가 프로세서를 사용할 수 있을 때까지 대기열에서 대기합니다. 메모리, 디스크 또는 네트워크 연결과 같은 다른 하드웨어를 추가하는 것으로는 프로세서 병목을 효과적으로 해결할 수 없고 문제만 커지는 경우가 대부분입니다. Windows 2000 Server에서 실행하는 IIS 5.0은 프로세서를 2개부터 4개까지 효율적으로 확장합니다. 프로세서를 추가하려는 경우에는 웹 사이트에 필요한 비즈니스 요구사항을 고려하십시오. 예를 들어, 주로 정적 컨텐트를 호스트하는 서버의 경우 프로세서 2개면 충분합니다. 동적으로 생성되는 컨텐트를 호스트하는 경우에는 프로세서를 4개 설치해야 문제를 해결할 수 있습니다. 그러나 사이트의 작업 부하가 CPU에 집중되면 한 대의 컴퓨터로 요청을 모두 처리할 수 없습니다. 이 경우에는 사이트를 여러 서버로 확장해야 합니다. 이미 여러 서버에서 사이트를 운영하고 있을 경우에는 서버를 더 추가할 것을 권장합니다. 그러나 Windows 2000 및 IIS 5.0에서 성능을 최대로 향상시키려면 메모리 문제를 해결해야 합니다. 웹 서버의 프로세서 수를 변경하는 결정을 내리기 전에 메모리 문제를 제외하고 다음 성능 카운터를 모니터링하십시오.
네트워크 용량, 대기 시간 및 대역폭네트워크는 클라이언트가 서버로 요청을 보내는 회선입니다. 서버로 요청을 보낸 다음 응답을 받을 때가지 걸리는 시간이 사용자가 가장 크게 느끼는 서버 성능 제한 요소 중 하나입니다. 이 요청/응답 주기를 대기 시간이라고 하는데, 대기 시간은 대부분 웹 서버 관리자가 제어할 수 없습니다. 예를 들어, 인터넷 상의 느린 라우터 또는 클라이언트와 서버 사이의 물리적 거리는 관리자가 해결할 수 없습니다. 주로 정적 컨텐트로 구성된 사이트에서는 네트워크 병목이 성능 병목의 가장 큰 원인입니다. 아주 작은 서버가 T3 연결(45mbps)이나 100mbps 고속 이더넷 연결을 완전히 포화시킬 수도 있습니다. 네트워크 연결을 조정하고 효과적인 대역폭을 최대로 활용하면 이러한 문제를 조금 줄일 수 있습니다. 효과적인 대역폭을 판단하는 가장 간단한 방법은 서버가 데이터를 보내고 받는 속도를 확인하는 것입니다. 서버의 여러 구성 요소에서 여러 가지 성능 카운터를 사용하여 데이터 전송을 측정할 수 있습니다. 사용할 수 있는 카운터는 웹, FTP 및 SMTP 서비스, TCP 개체, IP 개체, 네트워크 인터페이스 개체 등입니다. 각 카운터는 서로 다른 OSI(개방형 시스템 상호 연결) 계층을 측정합니다. 자세한 카운터 목록과 분석 내용은 Windows 2000 Server 리소스 키트에 포함된 인터넷 정보 서비스 5.0 리소스 가이드를 참조하십시오. 그 중에서 특히 서버 모니터링 및 조정 장에 있는 네트워크 I/O 단락을 참조하십시오. 그러나 시작할 때는 다음 카운터를 사용하십시오.
디스크 최적화IIS 5.0은 디스크에 로그를 쓰기 때문에 클라이언트 캐시 적중률이 100%일 경우에도 주기적으로 디스크 작업을 합니다. 즉, 로깅보다 디스크 읽기 작업이 많으면 시스템의 다른 영역을 조정해야 합니다. 예를 들어, 하드 페이지 부재가 발생하면 많은 양의 디스크 작업이 수행되지만 RAM은 부족하다는 것을 나타냅니다. 메모리 액세스가 디스크 검색보다 백만 배 정도 빠르기 때문에 요청에 응답하기 위해 하드 디스크를 검색하면 성능이 떨어지는 것이 당연합니다. 호스트하는 사이트 종류가 디스크 검색 빈도에 큰 영향을 미칠 수 있습니다. 사이트에 불규칙적으로 액세스되는 큰 파일이 있거나, 사이트에 있는 파일이 점점 커지거나, RAM 크기가 아주 작은 경우에는 IIS가 빠른 액세스를 위해 파일 사본을 RAM에 유지할 수 없습니다. 일반적으로 서버에 요청이 많을 경우에 디스크 읽기 횟수가 급격히 증가하는 것을 보려면 물리적 디스크 카운터를 사용합니다. RAM이 충분할 경우에는 동일한 서버에 데이터베이스가 저장되어 있거나 클라이언트가 다른 쿼리를 만들지만 않으면 대부분의 연결에서 캐시 적중 결과를 얻을 수 있습니다. 이 경우에는 캐싱이 수행되지 않습니다. 로깅도 디스크 병목의 원인이 될 수 있습니다. 서버에 디스크를 집중적으로 사용하는 문제가 없는데도 많은 양의 디스크 작업이 수행되면 즉시 서버의 RAM 크기를 검사하여 메모리가 충분한지 확인해야 합니다. 디스크 액세스 빈도를 확인하려면 다음 카운터를 로깅하십시오.
보안전자 상거래 웹 사이트를 운영할 경우 웹 응용 프로그램의 보안 문제와 성능 사이의 균형을 조정하는 것이 가장 중요한 문제 중 하나입니다. 보안 웹 통신을 하려면 보안을 하지 않는 웹 통신보다 많은 리소스가 필요하기 때문에 어떤 경우에 SSL 프로토콜이나 IP 주소 확인과 같은 다양한 보안 기술을 사용해야 하는지 그리고 어떤 경우에 보안 기술을 사용하지 않아도 되는지 알아야 합니다. 예를 들어, 홈 페이지나 검색 결과 페이지는 SSL을 통해 실행할 필요가 없습니다. 그러나 사용자가 체크아웃 페이지나 구매 페이지로 이동할 때는 해당 페이지에 대한 보안이 필요합니다. SSL을 사용할 경우 첫 번째 연결을 구성하는 비용이 SSL 세션 캐시의 보안 정보를 사용해서 다시 연결하는 비용보다 5배 정도 많은 듭니다. SSL 세션 캐시에 대한 시간 초과 기본값이 Windows NT 4.0에서는 2분이었는데 Windows 2000에서는 5분으로 변경되었습니다. 이 데이터가 플러시되고 나면 클라이언트와 서버가 완전히 새로운 연결을 구성해야 합니다. 긴 SSL 세션을 지원할 계획이면 ServerCacheTime 레지스트리 설정을 사용해 시간 초과 설정을 늘릴 수 있습니다. 수천 명의 사용자가 SSL을 사용하여 사이트에 연결할 것으로 예상될 경우 SSL 세션의 지속 시간을 예측한 다음 ServerCacheTime 매개 변수를 예측한 값보다 조금 길게 설정하면 안전합니다. 시간 초과를 이 값보다 훨씬 길게 설정하면 서버 캐시에 오래된 데이터가 남아 있을 수 있습니다. 또 HTTP 연결 유지 기능도 사용하십시오. HTTP 연결 유지 기능을 사용하면 브라우저에서 연결을 종료할 때까지 SSL 세션이 만료되지 않습니다. Windows 2000 및 IIS 5.0 보안 서비스는 성능 비용이 드는 보안 기술 외에도 많은 운영 체제 서비스에 통합됩니다. 따라서 각 서비스와 분리하여 보안 기능을 모니터링할 수 없습니다. 대신 일반적인 방법으로 보안 기능을 사용하는 경우와 사용하지 않는 경우에 테스트한 서버 성능을 비교하여 보안 오버헤드를 측정할 수 있습니다. 이 테스트를 수행할 때는 작업 부하와 서버 구성을 고정하여 보안 기능을 유일한 변수로 만들어야 합니다. 다음과 같은 항목을 측정하여 테스트할 수 있습니다.
서버에서 IIS 5.0을 실행하면서 도메인 컨트롤러로도 사용하면 도메인 서비스에 필요한 프로세서 사용, 메모리, 네트워크 및 디스크 작업 등의 비율이 높아져서 이 리소스에 대한 부하가 크게 증가됩니다. 작업이 증가하면 IIS 5.0 서비스가 효율적으로 실행되지 않을 수 있습니다. 따라서 도메인 컨트롤러에서는 IIS 5.0을 실행하지 않는 것이 좋습니다. 웹 응용 프로그램 모니터링완벽하게 설계하여 철저하게 테스트한 응용 프로그램으로 불완전한 응용 프로그램을 업그레이드하면 성능을 30배까지 크게 향상시킬 수 있습니다. 그러나 웹 응용 프로그램이 백 엔드 대기 시간(예: AS/400과 같은 레거시 시스템)의 영향을 받을 수 있습니다. 여러 가지 이유로 원격 데이터 원본이 성능 문제를 일으킬 수 있습니다. 개발자가 다른 웹 사이트에서 데이터를 가져오도록 응용 프로그램을 설계했는데 해당 웹 사이트가 중단되면 서버에 병목이 발생할 수 있습니다. 응용 프로그램이 원격 SQL Server 데이터베이스에 액세스할 경우 데이터베이스가 받은 요청을 처리하는 데 문제가 발생할 수 있습니다. 사용자가 사이트의 SQL 데이터베이스 관리자일 수도 있지만 데이터베이스가 원격 시스템에 있을 경우에는 서버를 모니터링하기 어려울 수도 있습니다. 또 데이터베이스 서버나 다른 백 엔드 서버를 제어하는 권한이 없을 수도 있습니다. 제어할 수 있으면 응용 프로그램과 작업을 하는 백 엔드 서버를 모니터링하고 웹 서버와 같은 방법으로 조정하십시오. 웹 응용 프로그램이 서버에 병목을 발생시키는지 확인하려면 다음 성능 카운터를 모니터링하십시오.
참고 ASP는 ISAPI 확장이며 두 번째 카운터에 의해 포함됩니다. 안정성 모니터링Microsoft® Windows® 2000 운영 체제에는 운영 체제와 컴퓨터의 다양한 상태를 모니터링하는 도구가 포함되어 있습니다. 이 문서에서는 이러한 도구, 도구의 메트릭 및 일반적으로 모니터링되는 몇 가지 상태에 대해 설명합니다. 이 문서에서는 도구의 기능에 대해 자세하게 설명하지 않고 일반적인 측정 상태를 설정하고 관리하기 위한 참고 사항만을 설명합니다. 안정성 및 가용성 메트릭운영 체제 중단 오류다른 모든 운영 체제와 마찬가지로 Windows 2000도 심각한 오류가 발생하여 응답하지 않는 경우가 있습니다. Windows 중단 오류가 발생하면 파란색 배경의 콘솔 비디오 화면에 텍스트 메시지가 표시되기 때문에 파란 화면이 나타난다고 합니다. 이 상태를 버그 확인이라고도 합니다. 다행스럽게도 운영 체제 중단 페이지가 자주 발생하지는 않습니다. 그래도 사용자는 이것을 주기적으로 모니터링해야 합니다. Windows 중단 오류를 처리하는 절차에 대한 자세한 설명은 이 문서의 범위를 벗어나는 내용입니다. 이 상태에 대한 자세한 내용을 보려면 Microsoft 기술 자료 페이지: http://www.microsoft.com/korea/support/default.asp를 참조하십시오. 그 중에서 다음 자료를 보면 자세한 정보를 얻을 수 있습니다.
Windows 이벤트 로그 서비스를 사용하면 운영 체제 중단 기록을 모니터링할 수 있습니다. 시스템을 다시 시작할 때 중단 오류가 이벤트 로그에 기록되고 중단 덤프가 Memory.dmp라는 영구 파일에 저장됩니다. 자세한 내용은 이 문서의 "이벤트 로그를 데이터 원본으로 사용하기" 단락에서 "덤프 저장"을 참조하십시오. 운영 체제 다시 부팅Windows 2000을 다시 부팅하는 이유는 운영 체제 업그레이드, 소프트웨어 설치, 하드웨어 유지 관리 등 여러 가지가 있습니다. 다시 부팅하면 시스템 이벤트 로그에 기록됩니다. 시스템이 안정적이면 시스템을 다시 부팅하는 빈도가 줄어듭니다. 따라서 오랜 시간 동안 기록된 다시 부팅 빈도를 보면 시스템 및 데이터 센터의 안정성을 확인할 수 있습니다. 자세한 내용은 이 문서의 "이벤트 로그를 데이터 원본으로 사용하기" 단락에서 "시작 이벤트"를 참조하십시오. 응용 프로그램 오류Windows 2000은 Dr. Watson 유틸리티를 사용하여 응용 프로그램 오류를 기록합니다. 이 유틸리티는 각 응용 프로그램 오류에 대한 정보를 시스템 루트의 Drwtsn32.log 파일에 추가합니다. 또한 이 유틸리티는 오류가 발생한 사용자 모드 응용 프로그램의 메모리 덤프를 포함하여 User.dmp 파일을 만듭니다. 운영 체제 중단의 경우와 마찬가지로 응용 프로그램 중단을 처리하는 절차에 대한 자세한 설명은 이 문서의 범위를 벗어납니다. 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오. Q94924. Postmortem Debugging Under Windows NT Q141465. How to Install Symbols for Dr Watson Error Debugging 응용 프로그램 오류가 응용 프로그램 이벤트 로그에 기록되기 때문에 이 이벤트가 기록된 빈도를 사용하여 분석할 수 있습니다. 자세한 내용은 이 문서의 "이벤트 로그를 데이터 원본으로 사용하기" 단락에서 "Dr. Watson 이벤트"를 참조하십시오. 운영 체제 가용성대부분의 사용자가 Windows 운영 체제에서 제공하는 응용 프로그램 서비스의 가용성에 많은 관심을 갖고 있습니다. 일반적으로 응용 프로그램마다 서로 다른 장치가 필요하기 때문에 일부 사용자는 응용 프로그램의 가용성을 직접 측정하는 것보다 운영 체제 가용성을 측정하는 것이 좋다고 생각합니다. 운영 체제 가용성을 측정하는 데 필요한 이벤트가 Windows 시스템 이벤트 로그에 포함되어 있습니다. 계획된 가용성과 총 가용성을 포함하여 다양한 종류의 가용성이 있습니다. 총 가용성은 전체 실행 시간에 대한 정상 작동 시간의 비율이고 시스템 이벤트 로그의 정보를 사용하여 쉽게 계산할 수 있습니다. 운영 체제 평균 복구 시간시스템의 가용성과 복구 기능 사이에는 밀접한 상관 관계가 있습니다. 시스템 복구 기능은 시스템이 중단되어 사용할 수 없는 시간을 측정한 값입니다. 일반적으로 이 값은 평균 복구 시간으로 보고됩니다. Windows 2000 운영 체제 이벤트 로그를 사용하여 쉽게 평균 복구 시간을 측정할 수 있습니다. 시스템 중단은 시스템이 종료될 때 시작되어 시스템이 다시 시작되면 끝납니다. 이 이벤트와 관련된 타임 스탬프를 캡처하는 방법은 이 문서의 "이벤트 로그를 데이터 원본으로 사용하기" 단락에서 "시작 이벤트", "정상 종료 이벤트" 및 "비정상 종료 이벤트"를 참조하십시오. 이벤트 로그를 데이터 원본으로 사용하기이벤트 뷰어 유틸리티이벤트 로그 서비스와 이벤트 뷰어를 사용하면 하드웨어, 소프트웨어 및 시스템 문제에 대한 정보를 수집하고 Windows 보안 이벤트를 모니터링할 수 있습니다. Windows 2000은 다음 세 종류의 로그를 기록합니다.
이벤트 뷰어에는 다음과 같은 이벤트가 표시됩니다.
이벤트 로그 서비스는 Windows를 시작할 때 자동으로 시작됩니다. 응용 프로그램 및 시스템 로그는 모든 사용자가 볼 수 있지만 보안 로그는 관리자만 액세스할 수 있습니다. 기본적으로 보안 로깅은 실행되지 않습니다. Windows 2000 그룹 정책을 사용하면 보안 로깅을 실행할 수 있습니다. 또 보안 로그가 모두 차면 시스템이 중단되도록 관리자가 레지스트리에 감사 정책을 설정할 수 있습니다. 그룹 정책을 사용하는 방법은 Windows 2000 설명서와 http://www.microsoft.com/windows2000/library 페이지에 있는 그룹 정책 백서를 참조하십시오. 이벤트 뷰어를 여는 방법
그림 1 이벤트 뷰어 이벤트 목록 내보내기이벤트 목록을 Microsoft Excel로 내보내 데이터를 저장하고 분석할 수 있습니다. 목록을 내보내는 방법
그림 2 이벤트 목록 내보내기 Excel 파일을 열면 다음과 같이 표시됩니다.
그림 3 내보낸 이벤트 데이터가 포함된 Excel 파일 이벤트 정렬이벤트를 정렬하여 데이터를 보다 쉽게 검토하고 분석할 수 있습니다. 정렬 순서 지정 방법
그림 4 정렬 순서 지정 참고 로그를 텍스트 형식이나 쉼표로 구분된 텍스트 형식으로 저장하면 저장되는 파일에 이 정렬 순서가 적용됩니다. 로그 파일 형식으로 이벤트 레코드를 저장하면 정렬 순서가 적용되지 않습니다. 이벤트 필터링검토하고 분석할 이벤트만 쉽게 볼 수 있도록 이벤트를 필터링할 수 있습니다. 이벤트 필터링 방법
그림 5 이벤트 필터링 이벤트 필터링을 종료하려면 보기 메뉴에서 모든 이벤트를 누르십시오. 시작 이벤트Windows 2000은 아래와 같이 시작 이벤트를 시스템 이벤트 로그에 기록합니다. 이벤트 로그 서비스 자체가 이 이벤트의 원본이고 이벤트 ID는 6005입니다. 이 이벤트의 시간은 대략 운영 체제를 응용 프로그램에 사용할 수 있게 되는 시간과 같습니다.
그림 6 이벤트 로그, 시작 이벤트 정상 종료 이벤트Windows 2000은 운영 체제 종료가 시작될 때마다 새 이벤트를 기록합니다. 여러 가지 메커니즘을 통해 정상 종료를 시작할 수 있습니다.
사용자가 직접 종료 화면을 사용하는 방법은 다음과 같습니다.
프로그래밍 방식은 다음과 같습니다.
이벤트 로그 서비스 자체가 이 이벤트의 원본이고 이벤트 ID는 6006입니다. 이 이벤트의 시간은 대략 운영 체제를 응용 프로그램에서 사용할 수 없게 되는 시간과 같습니다.
그림 7 이벤트 로그, 정상 종료 이벤트 비정상 종료 이벤트Windows 2000은 정상 종료 이외의 다른 메커니즘을 사용하여 운영 체제가 종료될 때마다 새 이벤트를 기록합니다. 가장 일반적인 원인은 시스템이 꺼지는 경우입니다. 이벤트 로그 서비스 자체가 이 이벤트의 원본이고 이벤트 ID는 6008입니다. 시스템이 다시 시작되고 이전에 완전하게 종료되지 않았다는 것을 Windows 2000이 확인하면 이벤트가 기록됩니다.
그림 8 이벤트 로그, 비정상 종료 이벤트 Windows 2000 Server를 실행하는 동안 시스템이 주기적으로 디스크에 타임 스탬프를 씁니다. 이 최근 작동 타임 스탬프가 Windows 2000 레지스트리에 저장되고 항상 이전 간격의 최근 작동 타임 스탬프를 덮어씁니다. 또한 최근 작동 타임 스탬프를 쓸 때마다 디스크에 플러시됩니다. 이렇게 컴퓨터가 중단되면 부팅 스탬프와 최근 작동 스탬프가 스트림의 마지막 두 항목으로 기록됩니다. 컴퓨터가 정상적으로 종료되면 정상 종료 타임 스탬프가 최근 작동 타임 스탬프를 덮어씁니다. 이 이벤트의 설명 부분에 있는 시간은 최근 작동 시간이므로 응용 프로그램에서 운영 체제를 사용할 수 없게 되기 직전의 시간입니다. Windows 2000 Server 운영 체제에서만 최근 작동 타임 스탬프가 기록됩니다. Windows 2000 Professional 운영 체제는 이 타임 스탬프를 유지하지도 않고 비정상 종료 이벤트도 기록하지 않습니다. 최근 작동 타임 스탬프는 레지스트리의 HKLM\Software\Microsoft\Windows\CurrentVersion\Reliability\LastAliveStamp에 기록됩니다. 최근 작동 타임 스탬프의 기본 간격은 5분입니다. 레지스트리 값 TimeStampInterval을 추가하여 간격을 변경할 수 있습니다. 이 값의 단위는 분입니다. 이 값을 0으로 설정하면 최근 작동 타임 스탬프는 기록되지 않고 정상적인 종료 스탬프만 기록됩니다. 시스템 버전 이벤트Windows 2000은 시스템이 시작될 때마다 운영 체제 버전 정보가 포함된 새 이벤트를 기록합니다. 따라서 나중에 운영 체제 버전에 따라 쉽게 Windows 2000 이벤트 로그를 처리할 수 있습니다. 이벤트 로그 서비스 자체가 이 이벤트의 원본이고 이벤트 ID는 6009입니다. 서비스 팩 설치Windows 2000은 서비스 팩 버전에 대한 자세한 정보를 시스템 이벤트 로그에 기록합니다. 따라서 나중에 운영 체제 버전에 따라 쉽게 Windows 2000 시스템 이벤트 로그를 처리할 수 있습니다.
그림 9 이벤트 로그, 서비스 팩 설치 이벤트 덤프 저장Windows 2000 Server 시스템에서는 운영 체제 중단 오류가 발생한 후에 항상 덤프 저장 이벤트가 생성됩니다. Windows 2000 Professional 시스템에서는 이 이벤트가 생성되지 않도록 할 수 있습니다.
그림 10 이벤트 로그, 덤프 저장 이벤트 Dr. Watson 이벤트Windows 2000은 응용 프로그램 오류를 Dr. Watson 로그 파일에 기록하고, Dr. Watson 유틸리티는 아래 그림과 같이 응용 프로그램 오류 이벤트를 Windows 2000 응용 프로그램 이벤트 로그에 기록합니다.
그림 11 이벤트 로그, Dr.Watson 이벤트 성능 모니터 사용시스템 성능 모니터는 관리자가 로컬 컴퓨터와 전세계에 있는 원격 컴퓨터에서 발생하는 여러 가지 상태를 모니터링할 수 있는 도구입니다. PerfMon은 개체 범주에 포함된 카운터 상태를 짧은 시간 동안 실시간으로 모니터링합니다. 아래에서 이러한 카운터 중 System Uptime을 설명합니다. System Uptime 카운터System Uptime 카운터는 시스템이 "작동"한 시간을 초 단위로 측정합니다. PerfMon은 수집된 결과를 화면에 도표로 표시하고, 사용자는 이 결과를 Excel 파일로 내보내 보고서를 작성할 수 있습니다.
그림 12 PerfMon System Uptime 카운터 경고임계값이 초과되면 경고하도록 PerfMon을 구성할 수 있습니다. 또 보고 기준과 보고 방법도 선택할 수 있습니다. 그림 13은 CPU 성능이 80%를 넘을 경우에 보고하도록 설정된 PerfMon입니다.
그림 13 PerfMon 경고 
최종 수정일 : 2001.1.29 | |
