보통 이 문제가 발생하게 되면 웹 페이지에 “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 미만인 경우 새로운 연결을 받는 것을 중지합니다.

문제 발생 원인 파악을 위해서는 메모리 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은 병렬처리를 해야됩에도 불구하고 직렬로 수행됨으로써 성능상의 문제를 유발시키는 것을 말합니다.

<IIS 5>

<IIS 6>

문제 발생 원인을 살펴보기 위해서는 메모리 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등이 있습니다

우선, 권한에 대한 문제가 발생하면 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

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

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를 바꾸는 것임을 알아두어야 합니다.

우선, 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 Bytes란 프로세스에서 필요한 메모리를 예약해 놓은 공간이라고 할 수 있습니다. 그리고, Private Bytes란 특정 프로세스에서 commit 한 메모리 공간으로, 실제 프로그램 상에서 1MB를 allocation 한다고 한다면 이는 private bytes의 1MB를 의미합니다. 따라서, 어떤 프로세스에서 메모리 누수가 발생한다고 하면, 이값을 참조하여야 합니다.

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