Internet Information Service

Application hang 으로 인한 웹 서비스 장애가 발생하였을 때 나타나는 대표적인 증상과 체크사항

mermaid207 — Mon, 12 Jan 2009 11:42:00 GMT

Hang은 웹 서버로부터 응답이 없어서 화면이 로딩 중이거나 혹은 빈 페이지로 표시되는 증상입니다. 또는 웹 서버로부터 응답이 상당히 느린 경우도 이에 해당됩니다. 문제 발생 하였던 시점의 이벤트 로그에 다음과 같은 경고 메시지가 남을 수 있습니다.

Event Type: Warning

Event Source: W3SVC

Event Category: None

Event ID: 1013

Description:

A process serving application pool 'DefaultAppPool' exceeded time limits during shut down.

The process id was <id>.

(응용 프로그램 풀 '%1'을(를) 지원하는 프로세스를 종료하는 동안 제한 시간이 초과되었습니다.

프로세스 ID는 '%2'입니다.)

Event Type: Warning

Event Source: W3SVC

Event Category: None

Event ID: 1010

Description:

A process serving application pool 'DefaultAppPool' failed to respond to a ping.

The process id was '<PID>'.

(응용 프로그램 풀 '%1'에 사용되는 프로세스가 Ping에 응답하지 못했습니다.

프로세스 ID는 '%2'입니다.)

문제 발생 원인 파악을 위해서는 메모리 Dump를 수집하여야 합니다.

IIS Diagnostics Toolkit (x86)

http://www.microsoft.com/downloads/details.aspx?FamilyID=9bfa49bc-376b-4a54-95aa-73c9156706e7&DisplayLang=en

문제 발생시 Debug Diagnostic tool에서 Tools 탭에 있는 “Create IIS Hang Dump”를 2~3번 정도 클릭하여 수동으로 Hang dump를 수집합니다. 단, IIS 관리자에서 모든 재활용 옵션을 체크하지 않은 상태에서 수집하셔야 합니다.

Hang은 CPU, Memory를 지속적으로 많이 소비하는 증상을 동반할 수도 있습니다. 이는 문제 발생 시 CPU와 memory 사용량이 어느정도인지 작업 관리자에서 확인이 가능합니다. 성능 탭에서 CPU 사용량과 할당된 메모리를 확인하고, 프로세스 탭에서 VM크기를 통해 프로세스별로 할당된 메모리의 양을 확인합니다. 성능 카운터 로그를 통해서도 리소스 사용량을 확인할 수 있는데, 다음 기술 문서에 나온 항목을 체크합니다.

http://technet.microsoft.com/ko-kr/library/cc671175.aspx

CPU/Memory 사용량이 높은 Hang 증상의 대표적인 원인을 알아보면, String Manipulation, Garbage Collection, 그리고 Infinite Loop 수행이 있습니다.

1. String Manipulation

문자열 연결을 자주 수행할 때 High CPU Hang이 발생할 수 있습니다. 따라서, 문자열 조작이 필요한 경우에는 String 개체 대신 StringBuilder를 사용하시기 바랍니다.

PRB: 웹 서비스 또는 Web Form의 높은 CPU 사용

http://support.microsoft.com/kb/307340

2. Garbage Collection

Garbage Collection이란 개발자로 하여금 메모리 관리 작업을 단순하게 처리하게끔 도와주는 매커니즘입니다. 하지만 빈번한 GC 작업은 웹 서버의 성능에 많은 영향을 주게 됩니다.

Garbage Collection: Microsoft .NET Framework의 자동 메모리 관리

http://www.microsoft.com/Korea/MSDN/MSDNMAG/ISSUES/2000/GCI/default.aspx

3. Infinite Loop

이는 개발자가 소스 코드에서 어떤 부분이 무한루프 수행을 유발시키는지 디버깅해야 합니다.

반면 CPU/Memory 사용량이 낮은 Hang 증상의 대표적인 원인에는 Critical Sections, Deadlock, Serialization 등이 있습니다. 즉, 리소스를 많이 소모할만큼 작업을 바쁘게 수행중이지는 않으나, 어떠한 원인으로 인해 클라이언트에서 응답을 줄 수 없거나 늦게 주는 상황을 말합니다.

1. Critical Sections

만약 3,4,5,6 번 쓰레드가 critical section을 갖고 있는 7번 쓰레드의 수행이 끝나기를 기다리고 있고, 7,8,9,10 번 쓰레드가 critical section을 갖고 있는 12번 쓰레드의 수행이 끝나기를 기다리고 있으며, 12,13,14 번 쓰레드가 critical section을 갖고 있는 4번 쓰레드의 수행이 끝나기를 기다리고 있다고 합시다. 이때 마침 critical section 을 갖고 있는 4번 쓰레드가 죽었다고 한다면, 이를 기다리고 있던 다른 쓰레드들은 계속 기다리고 있는 상태로 머무르게 됩니다.

2. Deadlock

서로 다른 쓰레드가 서로 상대 쓰레드의 수행결과를 기다리고 있는 상태를 말합니다.

3. Serialization

어떤 프로세스를 수행하는 쓰레드들이 무수히 많이 존재하고, 각각의 쓰레드들이 한 파일에 수행결과를 기록해야 작업이 끝나도록 만든 로직이 있습니다. 이럴때는 한쓰레드가 파일을 write 하는 동안 그밖의 다른 쓰레드들은 기다려야 되는 현상이 발생하게 됩니다. 즉, Serialization은 병렬처리를 해야됩에도 불구하고 직렬로 수행됨으로써 성능상의 문제를 유발시키는 것을 말합니다.

메모리 누수로 인한 웹 서비스 장애가 발생하였을 때 나타나는 대표적인 증상과 체크사항

mermaid207 — Mon, 12 Jan 2009 11:42:00 GMT

메모리 누수란 메모리 사용량이 증가하여 가용 메모리가 부족한 현상을 말합니다.

보통 이 문제가 발생하게 되면 웹 페이지에 “Out of Memory Exception”라는 에러메시지가 나타납니다.

문제 발생 원인을 알기 위해서 특정 프로세스에 대해 Memory Leak Rule을 설정하고 메모리 Dump를 수집하여야 합니다.

IIS Diagnostics Toolkit (x86)

http://www.microsoft.com/downloads/details.aspx?FamilyID=9bfa49bc-376b-4a54-95aa-73c9156706e7&DisplayLang=en

보통 메모리 누수는 어떤 객체가 메모리를 사용을 마친다음 반환를 안할 경우에 발생하게 됩니다. 이를 해결하기 위해서는 적절한 시점에 할당된 메모리를 해제하도록 코드를 수정하여야 합니다.

이 밖에 IIS6에서 요청이 처리되지 않고 서버를 재시작함으로써 문제가 해결되었다면 HTTPERR.LOG 파일에서 Connections_Refused가 기록되어 있는지 확인합니다. 만약 문제 시점에 Connections_Refused가 연속해서 발생하였다면 Non-paged pool memory에서 메모리 누수가 발생하였다는 것을 의미합니다. Non-paged Pool memory란 Paging되지 않는 system memory heap으로 언제나 physical memory에 상주하는 virtual address memory입니다. Non-paged pool memory가 20MB이하인 경우 Http.sys 드라이버는 가용한 운영체제 자원에 영향을 줄이기 위해 새로운 연결을 받는 것을 중지하게 됩니다.

문제를 해결하기 위해서 boot.ini 에 설정된 3GB 옵션이 설정되어 있는지 확인하고 설정되어 있다면 이를 해제합니다. 기본적으로 Kernel Mode memory 와 User Mode memory 에 2GB 씩 할당되었다면, 위 설정은 User Mode memory에 3GB 를 설정함으로써 상대적으로 Kernel Mode memory가 줄어들게 만듭니다. 또한, Workaround로 이 문제를 완화하기 위해 EnableAggressiveMemoryUsage 레지스트리 키를 설정하는 방법도 있습니다. 이 값을 설정하면 Http.sys 드라이버는 가용한 Non-paged pool memory가 8MB 미만인 경우 새로운 연결을 받는 것을 중지합니다.

Application crash 로 인한 웹 서비스 장애가 발생하였을 때 나타나는 대표적인 증상과 체크사항

mermaid207 — Mon, 12 Jan 2009 11:41:00 GMT

"IIS Crash"는 IIS 관련 프로세스가 비정상 종료할 경우를 의미합니다. 일반적으로 crash가 발생하게 되면 브라우저에서는 “500 – Internal Server Error(내부 서버 요류)”와 함께 “페이지를 표시할 수 없습니다”라는 에러 메시지가 표시됩니다. 문제 발생 당시 이벤트 로그에는 다음과 같은 경고 메시지가 남게 됩니다.

<IIS 5>

Event Type: Error

Event Source: Service Control Manager

Event Category: None

Event ID: 7031

Description:

World Wide Web Publishing Service 서비스가 예기치 않게 X번 종료했습니다. X 밀리초 안에 다음의 수정 작업을 합니다: 서비스 다시 시작.

<IIS 6>

Event Type: Warning

Event Source: W3SVC

Event Category: None

Event ID: 1011

Description:

A process serving application pool '<appPool_name>' suffered a fatal communication error with the World Wide Web Publishing Service. The process id was 'XXXX'.

Event Type: Warning

Event Source: W3SVC

Event Category: None

Event ID: 1009

Description:

A process serving application pool ‘<appPool_name>’ terminated unexpectedly. The process id was ‘XXXX’.

문제 발생 원인을 살펴보기 위해서는 메모리 Dump를 수집하여야 합니다. "메모리 Dump”란 프로세스의 메모리 순간 상태 정보를 Disk에 파일로 저장하는 단계를 의미합니다. Crash에 관한 Dump를 수집하기 위해 아래 나와있는 Debug Diagnostic tool에서 문제가 발생하기 전에 rule을 세팅합니다. 이후, 문제가 발생하였을 때 덤프가 수집되면 Debug Diagnostic tool의 dump count가 증가하게 됩니다.

IIS Diagnostics Toolkit (x86)

http://www.microsoft.com/downloads/details.aspx?FamilyID=9bfa49bc-376b-4a54-95aa-73c9156706e7&DisplayLang=en

Crash 증상의 대표적 원인에는 Stack Overflow, Stack Corruption, Heap Corruption, Divide by Zero, Null Pointer Exception을 포함한 Unhandled Exception등이 있습니다

권한/구성 문제로 인한 웹 서비스 장애가 발생하였을 때 나타나는 대표적인 증상과 체크사항

mermaid207 — Mon, 12 Jan 2009 11:40:00 GMT

권한이나 구성상의 문제는 IIS와 관련해서 권한 설정이나 환경 설정이 잘못되었을 때 발생하게됩니다.

우선, 권한에 대한 문제가 발생하면 IIS 상태코드를 참고하여 세부 오류 내용을 확인합니다. 주로 웹 페이지나 IIS 웹 서비스 로그에 403과 401오류가 남습니다.

IIS 상태 코드

http://support.microsoft.com/kb/318380

IIS 6.0의 기본 사용 권한 및 사용자 권한

http://support.microsoft.com/kb/812614

그중 대표적인 권한 오류로 401.1 을 들 수 있습니다. 이는 IUSR 계정의 비밀번호가 일치하지 않아 익명로그인에 실패하여 발생하게 됩니다. 이를 해결하기 위해서는 아래 기술 문서를 참고로 메타베이스, 도메인혹은 로컬 사용자, 구성요소서비스에 암호를 동기화하여 주는 작업이 필요합니다.

구성된 ID가 IWAM 계정에 올바르지 않다

http://support.microsoft.com/kb/297989/ko

그리고 구성상에 문제가 발생할 경우에는 IIS 설정을 백업한 다음 설정 상에 틀린부분이 있는지 확인합니다.

HOWTO: IIS 백업 및 복원

http://support.microsoft.com/?id=302573

네트워크 문제로 인한 웹 서비스 장애가 발생하였을 때 나타나는 대표적인 증상과 체크사항

mermaid207 — Fri, 09 Jan 2009 12:08:00 GMT

우선, Client에서 Web Server의 특정 포트로부터 응답이 없는 증상을 들 수 있습니다. 문제발생 원인을 규명하기 위해 체크해야할 사항은 다음과 같습니다.

1. TCPView, Netstat를 통해 해당 포트를 어떤 프로세스에서 사용하고 있는지를, 웹 서버에서 얼마나 많은 포트가 열려있는지 확인합니다. 만약 해당 포트를 제3사 응용 프로세스에서 사용한다면, 해당 서비스를 중지하고 웹 사이트를 시작하여 문제를 해결할 수 있습니다.

2. 혹은 기존 포트 연결이 많아 동적 사용자 포트가 부족하여 추가연결을 생성하지 못하고 있다면, MaxUserPort 레지스트리 값을 65534 으로 설정하여 주시기 바랍니다. 이 레지스트리 값은 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 아래 존재합니다.

3. 다음으로 Network Monitor log를 수집하여 패킷이 정상적으로 전송되는지 확인합니다. 문제라고 인식되는 원인으로 Web Server와 Client 통신 중 RST ACK로 응답하는 경우가 있습니다.

3-1. 이러한 증상의 첫번째 원인은 Web Server에서 해당 포트로 SYN을 보내지만, Web Server 와 Client 사이에 방화벽이 설정되어 있거나 네트워크 장비가 존재할 경우 Client 로부터 패킷을 받지 못하여 Web Server 에서 RST을 보내는 것입니다. 이 경우, Web Server 와 Client 사이에 Proxy server, Firewall의 문제가 있는지 확인해야 합니다. 웹 가속기도 문제 발생 원인이 될 수 있으므로 웹 가속기와 함께 사용하는 필터를 일시적으로 비활성화하여 테스트하여 봅니다.

3-2. 두번째 원인은ListenBackLog, ServerListenBacklog값이 적은 경우입니다. 이를 해결하기 위해서는 ListenBackLog는 레지스트리에서, ServerListenBacklog는 인터넷 서비스 관리자 혹은 메타베이스에서 조정하여야 합니다.

3-3. 마지막으로 수많은 SYN 요청이 다른 IP 주소로부터 유입될 경우, 즉 TCP/IP 공격을 할 경우 입니다. 이를 예방하기 위해서 다음 기술문서를 참고하여 TCP/IP 스택을 강화하여 주시기 바랍니다. 다음 기술문서를 참고하여 SynAttackProtect, TcpMaxPortsExhausted, TCPMaxHalfOpen, TCPMaxHalfOpenRetried 레지스트리 값을 설정하여 주시기 바랍니다. http://support.microsoft.com/kb/315669

추가적으로 Windows Server 2000(IIS5) 이고 컨텐츠들이 NAS 장비에 있을때 Web Server로부터 응답이 느린 증상이 발생할 수 있습니다.

IIS5에서는 SMB Protocol 을 통해서 파일 변경 통지 정보를 listening 하게 됩니다. 여기서 SMB(Server Message Block)는 네트워크를 통해 원격지 컴퓨터 상의 파일이나 서비스에 대한 요구를 할 수 있게 하는 프로토콜입니다. 이 때 두 서버 사이에서 Maxcmds 값의 협상이 이루어 지고, 보다 작은 값으로 정해지게 됩니다. 따라서 이 경우, 클라이언트 쪽에서는 MaxCmds 레지스트리 값(권장값:2048)을, 서버쪽에서는 MaxMpxCt 레지스트리 값(권장값:2048)을 늘려주어야 합니다.

네트워크 이슈 원인 파악을 위해 기본 자료외에 다음과 같은 자료를 수집하여야 합니다.

1. Network Monitor

이 tool은 지정 네트워크 구간에 있는 네트워크 패킷 흐름을 모니터링하는데 사용됩니다.

수집 과정

1> 아래 경로에서Network Monitor Tool를 다운받아 설치합니다.

http://www.microsoft.com/downloads/details.aspx?FamilyID=f4db40af-1e08-4a21-a26b-ec2f4dc4190d&DisplayLang=en#filelist

2> 네트워크 모니터를 실행한 후, 메뉴바에서 Capture ->Networks를 실행하여, Local Computer(네트워크 모니터를 설치한 머신)의 Mac Address를 확인합니다.

3> Capture->Buffer Settings에서 Buffer Size를 100MB로 설정합니다.

4> Capture->Filter에서 Address Pair는 *Any<->*Any 인지 확인합니다.

5> Network Monitor Capure를 시작합니다. (Capture->Start 메뉴를 실행합니다.)

6> 문제를 재현합니다.

7> Capture를 중지합니다. (Capture->Stop 메뉴를 실행합니다.)

8> 네트워크 모니터 로그를 File->SaveAs를 통하여 저장합니다.

2. Netstat

수집 과정

Netstat –an > netstat.txt (IIS5)

Netstat –ano > netstat.txt (IIS6)

3. TCPView

수집 과정

TCPView for Windows v2.51

http://www.microsoft.com/technet/sysinternals/Networking/TcpView.mspx

4. ping, telnet 테스트

Ping <서버명/서버IP>

telnet <서버명/서버IP> :80

Metabase

mermaid207 — Tue, 25 Nov 2008 07:45:00 GMT

1. Metabase Overview

메타베이스에는 IIS에게 어떤 포트를 사용하고, 어떤 request 처리하고, 어떤 Mime 타입은 처리하지 않으며, 어떤 applicaiton pool을 사용하는 등 IIS 동작에 대한 모든 설정을 담고 있습니다.

결국 IIS 서비스와 관련된 프로세스들은 메타베이스 정보를 알고 있어야 한다는 것을 의미합니다. 특히, 정보를 알고 있다는 것이 Metabase.xml 문서를 수시로 로드하는것이 아니라 IIS 서비스와 관련된 프로세스들이 메모리에 메타베이스 내용을 갖고 있다는 것을 의미합니다.

2. Metabase History

IIS 4 에서는 IIS 등록 정보 설정이 레지스트리에 있었습니다. 따라서 윈도우 백업과 복구, 서비스 팩 설치 와 같은 작업들이 IIS 설정에 오류를 발생시킬 수 있었습니다.

IIS 5에서는 IIS 등록 정보가 바이너리 파일로 저장되었습니다. 하지만 이를 관리하고 편집하기 쉽지 않았고, 이 역시 파일이 변조되면 복구가 힘들다는 단점이 있었습니다.

따라서 IIS6으로 오면서 xml 형식의 가독성 있는 텍스트 파일로 바뀌었고, 이로써 IIS 설정에 대해 편집 및 관리가 편리해 졌습니다.

또한 Metabase.xml 을 직접 편집해서 관리할 수 있지만 Adsutil.vbs 를 통해 자동화, 일관된 작업을 구현할 수도 있게 되었습니다.

3. Metabase Structure

메타베이스는 다음과 같은 hierarchical한 구조로 되어 있습니다.

- Service

   - Site
      - root

         - Virtual Directory

            - Directory

               - File

즉, /LM/Service/Site/ROOT/VirtualDirectory/Directory/File 와 같이 표시됩니다. 예를 들어, LM/W3SVC/1 의 위치에는 첫번째 웹 사이트에 대한 속성 값들을 지정하게 됩니다.

4. Metabase Communications Layer

파일에 있는 내용과 메모리에 있는 내용이 동시에 어떻게 관리되는지에 대해 생각해 봅시다. 우선, IIS 가 시작되면 metabase.xml파일에 있는 내용이 로드됩니다. 만약 IIS 관리자에서 설정을 변경을 하게 되면 메모리에 있는 데이터를 우선 바꿉니다. 따라서 적용한 즉시 수정된 사항이 xml 문서에 반영되는 것이 아니라 변경한 지 2분 후에 메모리에 있는 내용이 xml 파일에 적용됩니다. IIS 에 대한 설정을 변경한 후에는 특별한 IISRESET 없이 바로 변경된 내용이 적용됩니다. 특정 웹 사이트의 포트나 MIME 타입을 바꿀 경우에는 IISRESET 을 할 필요는 없지만, 프로세스 모델이 바뀔 경우 즉 IIS 5.0 호환 모드로 돌리고자 하는 경우에는 IIS RESET을 해야 합니다.

특히, IIS 서버에 백신이 작동하고 있을 경우 “C:\Windows\system32\inetsrv” 폴더를 검색 대상에서 제외시켜야 합니다. IIS는 메타베이스를 2분 마다 수정, 편집 하므로 이 행동이 바이러스 동작으로 오해되어 메타베이스 파일이 지워질 가능성이 있습니다. 참고로, IIS 관리자의 “Edit While Running” 을 체크한 상태에서 메타베이스를 변경하거나 ”Adsutil” 을 통해 메타베이스를 바꾸는 것은 in-memory metabase를 바꾸는 것임을 알아두어야 합니다.

Internet Information Service Overview

mermaid207 — Tue, 25 Nov 2008 05:35:00 GMT

IIS는 기본적으로 IE로부터 전달되어 온 요청에 대해 처리하는 기능 뿐만 아니라 응용 프로그램을 사용하여 다양한 처리를 효과적으로 수행할 수 있습니다. IIS 5.0에서는 Inetinfo.exe 프로세스에서 80포트를 바인딩하고 웹 서비스를 관리하게 되며 응용 프로그램들은 dllhost.exe라고 하는 단일의 프로세스에서 실행되게 됩니다.

우선, IIS 서버로 들어온 요청은 Inetinfo.exe 에서 처리되는데, 이 때 filter가 등록되어 있을 경우에는 이를 반드시 거치게 됩니다. 물론, filter에서 처리된 다음 바로 응답을 받는 경우도 존재합니다. 만약 요청된 컨텐츠가 정적인 콘텐츠이고, 캐쉬 메모리에 요청된 컨텐츠가 존재한다면 빠르게 응답을 줄 수 있습니다. 그리고, 동적인 컨텐츠들은 dllhost.exe 안의 thread에 의해 요청이 처리 됩니다. Dllhost.exe는 thread 의 pool을 갖고 있어 여러 응용프로그램을 단일의 프로세스에서 처리하도록 할 수 있습니다. 만약 pool에서 실행되는 하나의 응용 프로그램이 오류를 발생시키면 같은 pool에서 수행중인 응용 프로그램에도 영향을 미칠 수 있습니다. 따라서 응용 프로그램을 보호하기 위해 dllhost.exe의 다른 인스턴스를 사용하여 격리 프로세스로 실행하도록 할 수 있습니다. 그리고 각 dllhost.exe 프로세스들끼리는 RPC 통신(svchost.exe)을 하게 됩니다.

전반적으로, IIS5.0 의 구조상 Inetinfo.exe 에 문제가 생길 경우 웹 서비스 자체를 하지 못한다는 문제점이 있습니다.

IIS 6.0에서 HTTP.SYS는 IE로부터 전달되어 온 요청을 수신하고 각 요청들을 대기열에 대기시킵니다. 각 요청 대기열은 각 어플리케이션 풀에 해당하며 이는 하나 이상의 작업자 프로세스로 이루어져 있습니다. 어플리케이션 풀에서 실행되는 작업자 프로세스는 HTTP.SYS에서 요청을 직접 가져와서 처리 후 응답을 돌려주게 됩니다. 여기서 어플리케이션 풀이란, 응용 프로그램의 쓰레드 풀로, w3wp.exe 프로세스안에 여러 쓰레드들이 ASP 및 ASP.NET 와 같은 요청들을 처리해줍니다.

여기서, 각각의 응용프로그램 확장자 별로 CPU 당 작업자 쓰레드 수가 정해져 있는데, ASP는 25개, ASP.NET 1.1 은 20개 입니다.

Virtual Memory

mermaid207 — Tue, 25 Nov 2008 05:19:00 GMT

가상 메모리란 실제 윈도우 메모리와 매핑된 4GB 주소 공간으로 이 중 2GB는 Kernel Mode 프로세스가 사용하며, 나머지 2GB는 User Mode 프로세스에서 사용하게 됩니다. Kernel 영역은 작업 관리자에서도 확인할 수 있듯이 paged pool 영역과 Non-paged pool 영역으로 나뉘게 됩니다. paged pool 영역은 Kernel이 사용하는 메모리 중 디스크에 매핑된 영역으로 300~350MB 까지 사용 가능합니다. 반면, Non-paged pool 영역이란 Kernel이 사용하는 메모리중 RAM 에 있는 영역으로 256MB까지 사용 가능합니다.

이 두 영역에서 발생하는 exception에 대해 알아보면 다음과 같습니다.

Kernel 영역에서 unhandled exception이 발생하게 되면 블루스크린이 나타나게 됩니다. 한편, User 영역에서 exception이 발생하면 First Chance Exception이 발생하고, User 영역에서 이 예외 처리를 담당하는 Handler 를 찾게 됩니다. 이때 찾을 수 없다면 Second Chance Exception이 발생하게 되며, Windows OS에서 Handler 를 찾게 됩니다.

추가적으로 메모리 관리에는 다음 세가지 개념이 연관되어 있습니다. Virtual Bytes란 프로세스에서 필요한 메모리를 예약해 놓은 공간이라고 할 수 있습니다. 그리고, Private Bytes란 특정 프로세스에서 commit 한 메모리 공간으로, 실제 프로그램 상에서 1MB를 allocation 한다고 한다면 이는 private bytes의 1MB를 의미합니다. 따라서, 어떤 프로세스에서 메모리 누수가 발생한다고 하면, 이값을 참조하여야 합니다.

마지막으로 Working Set 이란 실제 물리적인 메모리 사용량을 의미하며, 이는 성능 문제가 발생할 때 참고할 수 있는 값입니다.

IIS 6.0 Architecture with Request Flow

mermaid207 — Mon, 24 Nov 2008 08:19:00 GMT

IIS 6.0 Architecture with Request Flow

IIS 5.0 Architecture with Request Flow

mermaid207 — Mon, 24 Nov 2008 08:17:00 GMT

IIS 5.0 Architecture with Request Flow

IIS Performance Counter Checklist

mermaid207 — Fri, 21 Nov 2008 13:58:00 GMT

IIS 웹 서버의 성능에 영향을 줄 수 있는 대표적인 리소스에는 processor, process, physical, network 이 있습니다. 여기서는 각각의 리소스 사용을 확인하기 위해 살펴보아야 할 성능 카운터항목은 무엇이며, 각 카운터가 의미하는 바가 무엇인지와 각 카운터의 병목을 판단할 수 있는 임계치 값에 대해서 알아보겠습니다.

1. Memory

메모리 성능 카운터는 IIS 웹 서버의 성능 문제가 발생했을때 가장 기본적으로 살펴보아야 할 요소입니다. 따라서, 현재 메모리가 충분한지 판단하고 사용 상태를 보는 것이 중요합니다. 메모리와 관련된 성능 병목이 있는지 확인하기 위해서는 다음 카운터를 살펴보아야 합니다.

Memory

Available Bytes

Committed Bytes

Page Reads/sec

Paging File

%Usage

각 항목이 의미하는 바는 다음과 같습니다.

l Memory / Available Bytes

현재 프로세스에서 사용할 수 있는 메모리의 바이트 수를 의미합니다. 다시말하면, 사용 가능한 RAM이 얼만큼 남았는지 보여주는 카운터입니다. 이 값의 임계치는 전체 메모리 크기의 5% 이하일 때 입니다.

l Memory / Committed Bytes

커밋된 가상 메모리의 양을 바이트 단위로 나타낸 것입니다. 커밋된 메모리란 디스크 페이징 파일에 예약된 공간이 있는 실제 메모리입니다. 이는 Available Bytes와 반비례 합니다.

l Memory : Page Reads/sec

프로세스가 메모리의 페이지를 요청하는데 시스템이 요청한 위치에서 해당 페이지를 찾을 수 없으면 페이지 부재가 발생합니다. 요청한 페이지가 메모리의 다른 위치에 있을 경우는 대부분의 프로세서가 큰 영향없이 처리할 수 있습니다. 하지만, 메모리가 아닌 디스크에서 페이지를 검색해야 할 경우 큰 지연 현상이 발생할 수 있습니다. Page Reads/sec는 이러한 페이지 부재를 해결하기 위해 디스크를 읽는 횟수를 의미합니다.

l Paging File : %Usage

현재 사용중인 페이징 파일의 백분율을 말합니다. 이 수치가 100%에 도달하게 되면 페이징 파일을 늘리거나 RAM을 더 추가시켜야 함을 의미합니다.

2. Processor

하나 이상의 프로세스가 프로세서 시간의 대부분을 사용할 경우 프로세서의 병목 현상이 발생할 수 있습니다. 이 경우 실행을 준비하고 있는 프로세스의 쓰레드가 프로세서를 사용할 수 있을 때까지 대기열에서 대기하게 됩니다.

Processor

%Processor Time

%Privileged Time

Process

%Processor Time

System

Processor Queue Length

각 항목이 의미하는 바는 다음과 같습니다.

l Processor / %Processor Time

모든 프로세스 스레드가 프로세서를 사용하여 명령을 실행하는 데 경과된 시간을 백분율로 나타낸 값입니다. 일반적으로 70% 이상이 사용되고 있다면 과부하라고 판단할 수 있습니다.

l Processor / %Privileged Time

%Privileged Time 이란 프로세서가 특권 모드(운영 체제 구성 요소 및 하드웨어 디바이스 드라이버를 위해 만든 처리 모드)로 실행된 시간을 백분율로 나타낸 값입니다. 반면, %User Time는 프로세서가 사용자 모드로 실행된 시간을 백분율로 나타낸 값을 말합니다. 이 값이 높으면 서버에서 응용 프로그램이 많이 실행되고 있음을 나타냅니다. 추가적으로, %Processor Time 은 %Privileged Time 과 %User Time을 합한 값을 의미합니다.

l Process / %Processor Time

모든 프로세스 스레드가 프로세서를 사용하여 명령을 실행하는 데 경과된 시간을 백분율로 나타낸 값입니다.

l System / Processor Queue Length

CPU큐에서 현재 실행이 되고 있지 않고 대기하고 있는 쓰레드의 수입니다. 일반적으로 이 값이 일정 기간 동안 CPU 수 x 2보다 크다면 서버의 프로세서 성능이 부족하다는 것을 말합니다..

3. Physical Disk

디스크는 서버에서 프로그램 및 데이터를 저장하고 처리하므로 디스크 사용량 및 속도에 영향을 미치는 병목 현상은 서버의 전체적인 성능에 큰 영향을 줍니다.

Physical Disk

%Disk Time

Average Disk Queue Length

각 항목이 의미하는 바는 다음과 같습니다.

l Physical Disk / %Disk Time

선택한 디스크 드라이브가 읽기 또는 쓰기 요청을 처리하는데 사용된 시간을 백분율로 나타낸 것입니다. 이 카운터가 100%가 되면 디스크 성능 상에 문제가 있음을 의미합니다.

l Physical Disk / Average Disk Queue Length

디스크가 읽기와 쓰기 요청을 수용할 정도로 빠르지 않으면 해당 요청은 대기열에 넣게 됩니다. 여기에서 이 값이 0보다 크면 디스크 자체에 병목 현상이 있음을 의미합니다.

4. Network

네트워크 병목 현상은 네트워크에서 데이터를 송수신하는 서버의 성능에 영향을 미칩니다. 서버의 네트워크 카드에 문제가 있을 수 있거나, 네트워크가 포화 상태여서 분할해야 할 수 있습니다. 다음 카운터를 사용하여 네트워크 병목 현상을 진단할 수 있습니다.

Network Interface

Bytes Total/sec

Output Queue Length

Web service

Bytes Total/sec

각 항목이 의미하는 바는 다음과 같습니다.

l Network Interface / Bytes Total/Sec
네트워크 인터페이스에서 주고 받는 초당 총 데이터의 수(Bytes) 또는 속도를 말합니다. 사용 가능한 대역폭과 이 값을 비교하면 발생할 수 있는 네트워크 병목 상태를 명확하게 표시할 수 있습니다. 일반적으로 바이트 수/초는 사용 가능한 총 대역폭의 50% 이하로 유지해야 합니다

l Network Interface / Output Queue Length

출력 패킷 큐의 길이를 의미하며, 이 값이 0보다 크면 네트워크 병목 현상을 의심해 볼 수 있습니다.

l Web Service / Bytes Total/sec

웹 서버에서 보내고 받은 바이트의 합계를 표시합니다.

참고 : http://technet.microsoft.com/ko-kr/library/cc671175.aspx

5. ASP

l ASP / Request Queued

ASP는 DLLHOST(Out of pooled) Process의 여러작업쓰레드에 의해 실행되고 있습니다. 실행중인 ASP가 있을 때 그 이후에 요청받은 ASP는 처리대기열에 쌓이게 됩니다.

먼저 들어온 ASP를 먼저 처리하겠지만, 앞에 실행중인 ASP가 제대로 처리 되지 않으면 대기열의 길이가 증가하게됩니다.

l ASP / Request Current

l ASP / Request/sec

ASP 의 요청 수를 확인할 때 참고하는 성능 카운터 입니다.

6. ASP.NET

l ASP.NET / Requests in Application Queue

서버 사용량이 많을 때 “HTTP 500 Web server too busy.“ (“HTTP 500 웹 서버 사용량이 너무 많습니다.") 에러가 발생합니다.