WindowsServer w3wp.exe 프로세서 cpu 사용률 100%
페이지 정보
본문
IIS 6.0 Troubleshooting
Windows Server 2003 버전에 포함되어 있는 Internet Information Server 6.0은 많은 중요 시스템의 FrontEnd 서버로 사용되고 있어 그 중요성이 날로 증가하고 있습니다. 여기서는 IIS 서비스의 예기치 않은 종료 현상, 성능 저하 및 응답 없는 현상에 대하여 문제를 정의하고 해결하는 과정을 설명 드립니다.
1. IIS 6.0 아키텍처
IIS 6.0이 이전 버전과 비교하여 크게 달라진 점은 http.sys 커널레벨 드라이버가 추가된 것과 dllhost.exe 프로세스가 아니라 w3wp.exe 프로세스에서 서비스되는 것입니다.
그 구체적인 모양을 그려 보면 다음과 같습니다. WWW 서비스는 w3wp.exe 프로세스가 전담하게 되면, WWW 서비스를 제외한 나머지 FTP, SMTP, NNTP 등의 서비스는 여전히 Inetinfo.exe 프로세스에서 서비스 됩니다.
이전의 구성과 비교해 보면 그 차이를 더욱 명확하게 확인할 수 있을 것 같습니다.
IIS 5.0까지는 모든 HTTP 요청이 Winsock을 거쳐 Inetinfo.exe에서 받은 다음, dllhost.exe 프로세스에서 응용 프로그램에 대한 처리가 발생하는 구조였습니다. 이런 상황에서는 inetinfo.exe 프로세스에 문제가 발생할 경우 전체 서비스가 영향을 받게 됩니다. IIS 6.0에서는 기본적인 요청을 HTTP.SYS 파일이 처리하게 되면 다른 모든 서비스는 w3wp.exe 프로세스에서 이루어 집니다.
HTTP.SYS 파일은 요청에 대한 큐와 캐시에 대한 역할을 주로 하여 거의 수정이 불가능하므로 매우 안정적으로 동작합니다.
보다 자세한 IIS 6.0에 대한 정보는 다음 사이트를 참고해 주세요.
Internet Information Services
http://www.microsoft.com/WindowsServer2003/iis/default.mspx
2. 자료 수집을 위해 사용되는 도구
문제 해결을 위한 과정을 먼저 설명 드리기 전에, 문제 정의와 해결을 위해 자주 사용되는 도구를 먼저 말씀 드리겠습니다.
가. MPSReports (Microsoft Product Support's Reporting Tools)
이 도구는 시스템 정보, 이벤트 로그, 네트워크 및 프로세스에 대한 정보 등을 자동으로 수집해 주는 도구 입니다. MPSReports는 여러 버전이 있는데요, IIS 문제를 해결하는데는 일반적으로 Networks 버전으로 수집하시면 좋습니다.
Microsoft Product Support's Reporting Tools
시스템 정보에서는 서버의 기본적인 구성과 로드된 모듈에 대한 정확한 버전 정보, 오류 보고 기능에 의해 발생한 오류 등을 확인할 수 있습니다.
PROCESSES 파일에서는 w3wp.exe 프로세스에 로드된 모듈에 대한 전체 목록을 확인할 수 있습니다. W3wp.exe 프로세스와 문제를 일으키는 널리 알려진 모듈이 있을 경우에 많은 도움이 됩니다.
이벤트 로그는 엔지니어에게 기본이 되는 사항입니다. 확인하셔야 할 이벤트 소스는 W3SVC가 되겠구요, 추가적으로 Application error, Application popup, Application hang, IISCTLS 등도 확인하셔야 합니다. 때에 따라서는 Service Control Manager, COM+에도 IIS 서비스와 관련된 오류가 기록될 수 있습니다.
나. Log Parser
IIS 문제 해결을 위하여 가장 많이 살펴보게 되는 것이 IIS 로그 및 HTTPERR 로그인데요, 때에 따라 로그의 크기가 매우 큰 경우가 있습니다. 이럴 때는 Log Parser를 이용하여 필요한 항목만 추출하여 문제 해결에 접근할 수 있습니다.
Log Parser 2.2
자주 사용되는 Log Parser의 SQL 구문을 파일에 저장해 놓고 조금씩 변형하여 사용하는 것도 좋은 방법입니다.
Logparser –iw:ON –i:W3C –o:W3C file:<<SQL 파일 경로>>
오류가 발생한 로그만 추출 SELECT * FROM ex*.log TO reports\HTTPErrors.log WHERE sc-status >= 500 AND NOT ( TO_LOWERCASE(cs-uri-stem) LIKE '%.bmp' OR TO_LOWERCASE(cs-uri-stem) LIKE '%.gif' OR TO_LOWERCASE(cs-uri-stem) LIKE '%.jpg' OR TO_LOWERCASE(cs-uri-stem) LIKE '%.swf' OR TO_LOWERCASE(cs-uri-stem) LIKE '%.css' OR TO_LOWERCASE(cs-uri-stem) LIKE '%.vbs' OR TO_LOWERCASE(cs-uri-stem) LIKE '%.js' OR TO_LOWERCASE(cs-uri-stem) LIKE '%.htm' OR TO_LOWERCASE(cs-uri-stem) LIKE '%.html' OR TO_LOWERCASE(cs-uri-stem) LIKE '%.doc' )
동적 페이지에 대한 요청만 추출 SELECT * FROM ex*.log TO reports\DynamicRequest.log WHERE NOT ( TO_LOWERCASE(cs-uri-stem) LIKE '%.bmp' OR TO_LOWERCASE(cs-uri-stem) LIKE '%.gif' OR TO_LOWERCASE(cs-uri-stem) LIKE '%.jpg' OR TO_LOWERCASE(cs-uri-stem) LIKE '%.swf' OR TO_LOWERCASE(cs-uri-stem) LIKE '%.css' OR TO_LOWERCASE(cs-uri-stem) LIKE '%.vbs' OR TO_LOWERCASE(cs-uri-stem) LIKE '%.js' OR TO_LOWERCASE(cs-uri-stem) LIKE '%.htm' OR TO_LOWERCASE(cs-uri-stem) LIKE '%.html' OR TO_LOWERCASE(cs-uri-stem) LIKE '%.doc' ) |
IIS 로그 및 HTTPERR 로그 파일에 나타나는 오류와 관련해서는 다음 문서를 참고해 주세요.
IIS 상태 코드
http://support.microsoft.com/?id=318380
HTTP API의 오류 로깅
http://support.microsoft.com/?id=820729
다. NETMON (Network Monitor)
IIS 서비스는 네트워크를 기반으로 하는 서비스이므로 문제 확인을 위하여 네크워크 모니터 도구로 패킷을 추적해야하는 경우가 많습니다. 특히 방화벽, 침입 탐지, 안티 바이러스 등의 보안 제품이 많은 경우에 문제 증상을 확인하고 해결하는데 많은 도움이 됩니다.
[NETMON 사용방법] 1. 네트워크 모니터를 처음 시작하시면 “네트워크 선택” 창이 보이는데요, 알맞은 네트워크 카드를 선택합니다. 만약 이 창이 보이지 않으면 메뉴 중 “Capture” >”Networks…”를 선택하시면 됩니다. 2. 메뉴 중 “Capture”>”Buffer Settings…” 메뉴를 선택한 다음 Buffer Size를 100M로 변경해 주세요. 3. 마지막으로 “Capture”>”Start”를 선택하면 패킷 수집이 시작됩니다. 문제가 발생하는 순간이 들어 있어야 하므로 패킷 수집에 신중을 기해 주시기 바랍니다. 4. “Capture”>”Stop”를 누르신 다음, “File”>”Save As…”로 저장해 주세요. |
수집된 네트워크 패킷을 분석하는 방법은 상황에 따라 많이 다르겠습니다만, 기본적으로 HTTP를 필터링해서 보셔야 하겠구요,응답이 정확히 도착했는지, 응답이 왔다면 IIS 서버로부터 왔는지 등을 확인하셔야 하겠습니다.
HTTP와 관련하여 Netmon 사용방법에 대한 자세한 사항은 아래 문서를 참고하세요.
How to View HTTP Data Frames Using Network Monitor
http://support.microsoft.com/?id=252876
라. 성능 카운터 로그
높은 CPU 사용, CPU가 주기적으로 튀는 현상, 높은 메모리 사용 등으로 인한 성능저하 등 리소스 부족이 문제의 원인으로 생각될 때는 성능 카운터 로그를 수집하셔야 합니다. 수집하셔야 항목은 다음과 같습니다.
[성능 로그 구성] 성능 모니터는 서버에 많은 영향을 미치므로 데이터 수집 간격을 60초 정도로 설정해 주시기 바랍니다. 덤프를 받고 난 후에 정지해 주시기 바랍니다.
1. "성능로그 및 경고(Performance logs and alerts)" 를 확장합니다. 2. "카운터 로그(Counter logs)" 를 오른쪽 클릭 합니다. 3. "새 로그 설정(New Log Settings)"을 선택합니다. 4. "이름(descriptive name)" 을 입력합니다. 5. 나중을 위해 로그파일 위치를 확인합니다. 6. "개체 추가(Add Object)" 버튼을 클릭합니다. 7. "성능개체(Performance Object)" dropdown에 의해서 선택하고 "추가(Add)" 합니다.
Processor Memory Process Web Service Active Server Pages Internet Information Services Global Network Interface Paging File Server System Thread
ASP.NET을 사용 중이시면 다음 성능 카운터를 추가합니다. .NET CLR Memory .NET CLR Data .NET CLR Exceptions .NET CLR Interop .NET CLR Jit .NET CLR Loading .NET CLR LocksAndThreads .NET CLR Networking .NET CLR Remoting .NET CLR Security ASP.NET ASP.NET Applications |
특히 Thread 항목은 로그 파일의 크기가 매우 크게 늘어 나므로 높은 CPU 사용이 문제가 될 때만 수집하셔야 합니다. 이렇게 수집한 성능 카운터 로그의 Thread 항목은 IIS 메모리 덤프 파일과 함께 분석에 사용되므로 수집간격도 짧게 잡아주셔야 합니다.
분석하실 때는 process 성능 개체의 inetinfo.exe, w3wp.exe 인스턴스에 대하여 % Processor Time, Virtual Bytes, Working Set 등의 카운터부터 확인하기 시작하는 것이 좋습니다.
IIS 서버와 관련된 성능 카운터 로그 수집 방법에 대한 자세한 정보는 아래 문서를 참고해 주세요.
IIS의 시스템 모니터에서 카운터 로그를 사용하여 웹 서버의 성능을 모니터링하는 방법
http://support.microsoft.com/?id=313064
마. DebugDiag (Debug Diagnostics)
대부분의 IIS 문제는 문제가 발생하던 시점의 메모리 덤프가 필요한 경우가 많습니다. 이럴 경우에 사용가능한 도구중 하나가 DebugDiag입니다. DebugDiag는 예기치 않게 서비스가 종료될 경우 덤프를 받아 주는 역할을 하며, 높은 CPU 사용 및 응답 없는 현상이 발생할 때 쉽게 IIS 관련 서비스의 덤프를 받을 수 있습니다.
IIS Diagnostics Toolkit
또한 DebugDiag 툴은 받은 덤프를 자동으로 분석하는 기능이 함께 있으므로 문제 시점에 받아진 덤프를 바로 분석해 보실 수 있습니다. 자동 분석을 하시면 많이 사용된 쓰레드에 대한 callstack 등을 보실 수 있으며, ASP로 구성된 사이트인 경우 문제 발생 라인을 표시해 주는 기능도 제공합니다.
DebugDiag로 crash 및 hang 덤프 구성 방법
[문제가 발생하기 전..] 1. DebugDiag 다운로드 및 설치합니다.
[옵션 구성] 1. DebugDiag의 Tools에서 Options & Settings를 선택합니다. 2. Preferences 탭에서 User service mode to overcome terminal server limitations (not persisted)를 체크합니다. (권장 옵션) Enable raw debugger logs. Includes debug output and engine messages를 체크합니다. 3. Performance Log 탭에서 Enable Performance Counter Data Logging를 선택하고, Data Sampling Interval 간격을 확인합니다.
[DebugDiag crash 구성] 1. DebugDiag를 시작합니다. 2. Select Rule Type 창에서 Crash을 선택합니다. 이 창이 보이지 않으면 Add Rule… 버튼을 클릭합니다. 3. Select Target Type 창에서 All IIS related processes 버튼을 클릭합니다. 4. Advanced Configuration (Optional) 창의 Unconfigured First Chance Exceptions에서 Mini Userdump를 선택하고 10을 입력합니다. Maxinum Userdump Limit에는 100을 입력합니다. 5. Advanced Configuration (Optional) 창에서 Breakpoints… 버튼을 클릭합니다.
a. Configure Breakpoints 창에서 Add Breakpoint… 버튼을 클릭합니다. b. Configure Breakpoint 창에서 Kernel32!ExitProcess를 선택하고, Action Type에서 Full Userdump를 선택한 다음, Action Limit에는 10을 입력하고 OK를 클릭합니다. c. 앞에서와 같이 Kernel32!TerminateProcess의 Action Type에서 Full Userdump를 선택한 다음, Action Limit에는 10을 입력하고 OK를 클릭합니다.
6. Select Dump Location And Rule Name 창에서 rule name과 Userdump Location을 확인합니다. 7. Rule Completed 창에서 activate the rule now를 선택합니다.
[DebugDiag hang 구성] 1. DebugDiag를 시작합니다. 2. Select Rule Type 창에서 IIS Hang을 선택합니다. 이 창이 보이지 않으면 Add Rule… 버튼을 클릭합니다. 3. Select URLs to monitor 창에서 Add URL 버튼을 클릭한 다음, 모니터링할 URL를 입력한다. 예를 들면 http://www.mydomain.com/default.aspx 등입니다. 여러 항목을 입력하실 수 있습니다. 4. Select Dump Targets 창에서 Add Dump를 클릭한 다음, All active IIS related process를 선택해 주세요. 5. Select Dump Location And Rule Name 창에서 Rule이름과 Dump의 위치를 확인합니다. 6. Rule Completed 창에서 activate the rule now를 선택합니다.
중요: 만약 Hang 증상이 발생하였는데, 덤프가 발생하지 않으면 DebugDiag의 Tools 메뉴에서 Create IIS Hang Dump를 클릭하시면 덤프가 강제로 생성됩니다. 1분 정도의 시간 간격을 두고 2번 정도 받아 주세요. (그림 참조)
[문제 발생 후..] 문제가 발생하면 DebugDiag는 자동으로 덤프를 받습니다. DebugDiag 창에서는 Userdump Count 값이 증가하게 됩니다. 덤프가 받아 졌으면 DebugDiag가 설치된 경로의 Logs 폴더 전체를 압축해 보내주시기 바랍니다.
|
바. IIS Tracing
성능 문제가 의심이 될 때, 이전 버전에서는 IIS 내부 프로세스를 추적할 수 없어 분석에 많은 어려움이 있었는데요, IIS 6.0 쉽게 Tracing을 하실 수 있습니다. Tracing은 IIS 로그보다 수집되는 양이 매우 많습니다.
IIS Trace 수집 방법 문제 상황을 확인하기 위하여 커널 Trace Log 및 다음과 같은 항목에 대하여 IIS Trace Log를 수집할 것입니다.
HTTP 서비스 추적 IIS: 요청 모니터링 IIS: IISADMIN 글로벌 IIS: SSL 필터 IIS: WWW 글로벌 IIS: WWW 서버 IIS: WWW Isapi 확장 IIS: ASP(Active Server Pages) ASP.NET Events COM+ Services
시스템에 따라서는 ASP, ASP.NET, COM+ 항목은 보이지 않을 수 있습니다. 웹서버에 대한 HTTP 요청이 한번 이상 있어야 추적항목이 로드되므로, IIS를 재시작 하셨을 경우에는 해당 페이지를 한번 호출해 주시기 바랍니다.
[IIS Trace Log] 1. 시작 > 모든 프로그램 > 관리 도구 > 성능 프로그램을 시작한 다음 새 추적을 만듭니다. 추적 로그의 이름은 MSIISTrace로 주시기 바랍니다.
2. MSIISTrace 창의 일반 탭에서 시스템 공급자가 아닌 공급자를 선택한 다음, 추가 버튼을 클릭합니다. 해당 창에서 앞서 말씀 드린 항목을 Ctrl 키와 함께 선택하신 다음 확인을 선택합니다.
3. 일정 탭에서 로그 시작 시간을 문제가 많이 발생하는 시간으로 설정합니다. 그리고 로그 중지 시간은 15분 정도로 설정해 주시기 바랍니다.
[Kernel Trace Log] 1. 커널 Trace 로그를 수집하기 위하여 앞서 새 추적 로그를 하나 더 만듭니다. 이름은 편의상 MSKernel로 만들겠습니다. MSKernel 창에서 시스템 공급자를 선택합니다.
2. 일정 탭에서 로그 시작 시간 및 중지 시간을 IIS Trace Log와 같게 설정해 주시기 바랍니다.
[Trace Log 수집 후] 해당 로그 파일은 C:\PerfLogs 폴더에 일반적으로 수집됩니다. 수집하신 etl 파일이 있는 곳으로 이동하신 다음, 다음 명령어를 입력합니다. Tracerpt MSIISTrace_2006060813.etl MSKernel_2006060813.etl –report –summary –f html 3개의 파일이 생성되는데요, 수집하신 파일과 함께 전달해 주세요. |
수집된 로그 파일을 여러 가지로 분석할 수 있습니다. 대표적인 방법은 DumpTraceReqs.js스크립트 파일로 파싱해 보는 것입니다.
----------------------------------------------------------------------------- Request n.425: http://testdomain.com:80/DetailView.aspx?ItemNo=A047125631 {00000000-0000-0000-01f3-0b60000000aa}
IISGeneral: GENERAL_REQUEST_START - IIS starts processing a new request SiteId: 1 ConnId: 1074524928 RawConnId: 0 RequestURL: http://testdomain.com:80/DetailView.aspx?ItemNo=A047125631 RequestVerb: GET ContextIDSeq: 425 Timestamp:
IISISAPI: ISAPI_START - IIS starts processing an ISAPI Request ContextIDSeq: 425 Timestamp:
IISGeneral: GENERAL_ISAPI_HANDLER - IIS processes an in-proc ISAPI request ContextIDSeq: 425 Timestamp:
W3Isapi: CALL_ISAPI_EXTENSION - Call Isapi Extension DllName: C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll ContextIDSeq: 425 Timestamp:
W3Isapi: ISAPI_EXTENSION_DONE - Isapi Extension Done ContextIDSeq: 425 Timestamp:
IISISAPI: ISAPI_END - IIS ends processing an ISAPI Request ContextIDSeq: 425 Timestamp:
IISGeneral: GENERAL_REQUEST_END - IIS ends processing a request BytesSent: 59538 HttpStatus: 200 HttpSubStatus: 0 BytesReceived: 3040 ContextIDSeq: 425 Timestamp:
Total time: 5000 msecs ----------------------------------------------------------------------------- |
사. 기타 유용한 도구들
IIS 5.0에서 메모리 덤프를 받을 때 주로 사용한 ADPlus를 포함하고 있는 Windbg (Debugging Tools for Windows) 프로그램은 아직도 매우 유용한 도구 있습니다.
Install Debugging Tools for Windows 32-bit Version
http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx
IIS 서버의 crash와 hang에 대한 덤프를 받을 때는 다음과 같은 명령을 입력합니다.
cscript adplus.vbs -crash -iis –quiet
cscript adplus.vbs -hang -iis -quiet
Filemon과 Regmon 등은 보안과 관련된 문제가 발생했을 때, 문제를 해결할 수 있는 매우 유용한 도구 입니다.
Filemon 사용법 1. 먼저 http://www.sysinternals.com에서 Filemon을 검색한 다음 알맞은 버전을 다운로드합니다. 현재는 다음과 같습니다. http://www.sysinternals.com/ntw2k/source/filemon.shtml
2. 압축을 풀고 filemon.exe 파일을 실행하면 실시간으로 모니터링을 시작합니다. 기본적으로 모든 사항을 모니터링하는데요 Ctrl + E를 누르시면 정지합니다. 그리고 Ctrl + L를 누르시면 필터링을 할 수 있습니다. Windows 2003 IIS 관련 작업만 모니터링하고 싶으면 inetinfo.exe;w3wp.exe와 같이 입력합니다. (구성요소 서비스를 이용하고 있으시면 dllhost.exe도 포함해 주세요) Ctrl + E를 다시 누르면 시작합니다.
3. filemon으로 권한과 관련된 작업을 해결할 수 없으면 regmon이란 툴로 레지스트리 관련 권한사항을 모니터링해야 합니다. 사용방법은 filemon과 유사합니다. http://www.sysinternals.com/utilities/regmon.html |
크게 보아 DebugDiag와 Logparser를 포함하고 있는 IIS Resource Kit은 아직도 많은 유용한 툴을 많이 가지고 있습니다.
Internet Information Services (IIS) 6.0 Resource Kit Tools
그 중에서도 WFetch는 HTTP와 관련된 원시 코드를 그대로 볼 수 있기 때문에 문제를 명확히 이해하는데 많은 도움이 됩니다.
3. 문제 정의 및 자료 수집
정확한 문제 정의는 문제 해결을 위해 무엇보다 중요합니다. 만약 같은 문제가 바로 재현이 가능하다면 문제를 명확하고 쉽게 정의할 수 있겠습니다만, 보통 문제가 일회성에 그치거나, 재현이 쉽지 않을 경우 그리고 문제 발생 시점의 상황을 전달 받는 경우에는 문제를 다시 정의해야 하는 경우가 발생할 수도 있습니다. 일반적으로 문제를 정의하기 위해서는 다음과 같은 기본적인 자료가 필요합니다.
- MPSReports
- IIS Metabase
- IIS Log
- HTTPERR Log
IIS Metabase는 XML 문서로 되어 있으므로 메모장 또는 인터넷 익스플로러 등에서 보실 수 있으며, 계정 정보 및 로드된 ISAPI 필터 및 확장 정보 그리고 응용 프로그램 풀에 대한 정보 등을 확인할 수 있습니다.
IIS 로그는 일반적으로 W3C 형식으로 받아지도록 구성되어 있습니다만, 문제 해결을 위해서는 다음과 같은 항목이 받아지도록 구성하는 것이 좋습니다. 특히 걸린 시간 항목은 응답 속도가 느려졌을 때에 필수적으로 확인해할 사항입니다.
- 날짜 ( date )
- 시간 ( time )
- 클라이언트 IP 주소 ( c-ip )
- 사용자 이름 ( cs-username )
- 서비스 이름 ( cs-sitename )
- 서버 IP 주소 ( s-ip )
- 서버 포트 ( s-port )
- 메서드 ( cs-method )
- URI 스템 ( cs-uri-stem )
- URI 쿼리 ( cs-uri-query )
- 프로토콜 상태 ( sc-status )
- Win32 상태 ( sc-win32-status )
- 보낸 바이트 수 ( sc-bytes )
- 받은 바이트 수 ( cs-bytes )
- 걸린 시간 ( time-taken )
- 사용자 에이전트 ( cs(User-Agent) )
가. 예기치 않은 종료
이벤트 로그에서 다음과 같은 오류가 있다면, IIS 서버가 예기치 않게 종료되었다는 것을 확인할 수 있습니다. 특히 W3SVC의 1009, 1011번 등의 오류는 IIS 서버의 예기치 않은 종료를 의미합니다.
6/15/2006 6/7/2006 6/14/2006 |
다음과 같은 오류는 조금 특이한 경우의 crash 현상이 되겠는데요, ntdll.dll 모듈과 충돌하여 종료된 것을 확인할 수 있습니다. 이와 같은 현상은 IIS 서버의 Heap Memory 영역이 손상되어 발생한 경우가 많습니다.
6/7/2006 |
Heap Memory 힙은 작은 청크로 분할되거나 할당될 수 있는 하나 이상의 메모리 페이지 영역입니다. 프로세스에서 필요한 객체의 수나 크기를 미리 알 수 없을 때, 동적 메모리 할당 지속시간이 쓰레드 활동기간보다 길 때, 또는 객체가 스택에 들어가기에 너무 클 때 힙 동작이 호출됩니다. 힙 손상은 주로 응용프로그램이 주어진 힙 메모리 블럭을 할당하고, 요청한 힙 블럭의 크기 이상의 메모리 주소를 쓸 때 발생합니다. 다른 일반적인 예는 응용프로그램이 이미 해제한 블럭에 쓰거나 다시 해제할 때 발생합니다. |
일반적인 crash의 경우에는 앞서 말씀드린 DebugDiag 툴로 crash 덤프를 받으면 되지만, 힙 손상일 경우에는 pageheap을 이용하여 덤프를 구성해 주셔야 합니다.
DebugDiag pageheap 구성 [문제가 발생하기 전..] 1. DebugDiag 다운로드 및 설치합니다. [옵션 구성] 1. DebugDiag의 Tools에서 Options & Settings를 선택합니다. 2. Preferences 탭에서 User service mode to overcome terminal server limitations (not persisted)를 체크합니다. (권장 옵션) Enable raw debugger logs. Includes debug output and engine messages를 체크합니다. 3. Performance Log 탭에서 Enable Performance Counter Data Logging를 선택하고, Data Sampling Interval 간격을 확인합니다. [pageheap 구성] 1. DebugDiag를 시작합니다. 2. Select Rule Type 창에서 Crash을 선택합니다. 이 창이 보이지 않으면 Add Rule… 버튼을 클릭합니다. 3. Select Target Type 창에서 A specific process 버튼을 클릭합니다. 4. Select Target 창에서 문제가 되는 프로세스를 선택합니다. 5. Advanced Configuration (Optional) 창의 Unconfigured First Chance Exceptions에서 Mini Userdump를 선택하고 10을 입력합니다. Maxinum Userdump Limit에는 100을 입력합니다. 6. Advanced Configuration (Optional) 창에서 Breakpoints… 버튼을 클릭합니다. a. Configure Breakpoints 창에서 Add Breakpoint… 버튼을 클릭합니다. b. Configure Breakpoint 창에서 Kernel32!ExitProcess를 선택하고, Action Type에서 Full Userdump를 선택한 다음, Action Limit에는 10을 입력하고 OK를 클릭합니다. c. 앞에서와 같이 Kernel32!TerminateProcess의 Action Type에서 Full Userdump를 선택한 다음, Action Limit에는 10을 입력하고 OK를 클릭합니다. d. Configure Breakpoint 창에서 ComSvcs!ComSvcsExceptionFilter를 선택하고, Action Type에서 Full Userdump를 선택한 다음, Action Limit에는 10을 입력하고 OK를 클릭합니다. 7. Advanced Configuration (Optional) 창에서 PageHeap Flags… 버튼을 클릭한 다음, Enable Normal PageHeap을 선택합니다. 8. Select Dump Location And Rule Name 창에서 rule name과 Userdump Location을 확인합니다. 9. Rule Completed 창에서 activate the rule now를 선택합니다. 10. 컴퓨터를 재시작하여 PageHeap 구성을 완료합니다. [문제 발생 후..] 문제가 발생하면 DebugDiag는 자동으로 덤프를 받습니다. DebugDiag 창에서는 Userdump Count 값이 증가하게 됩니다. 덤프가 받아 졌으면 DebugDiag가 설치된 경로의 Logs 폴더 전체를 압축해 보내주시기 바랍니다. |
예기치 않은 종료 문제을 해결하기 위해서는 먼저 기본적인 자료를 받아서 어떤 프로세스에서 예기치 않은 종료 현상이 발생했는지 확인합니다. 그런 다음 확인된 프로세스에 대해 DebugDiag를 구성합니다. 만약 힙 손상으로 발생한 문제라면 pageheap을 이용하여 DebugDiag를 구성합니다. 문제가 재현되어 덤프가 받아지면 해당 덤프를 분석합니다.
나. 응답 없음
메모리나 CPU의 사용이 많지 않으면서 서버의 응답 속도가 매우 느리거나, 아무런 반응이 없는 경우가 있습니다. 이와 같은 경우에는 오류가 특별히 발생하지 않는 것도 하나의 특징입니다. 보통 IIS 로그를 확인해 보면 time-taken 항목의 값이 매우 높고 성능 카운터 로그에서 대기하고 있는 요청들이 높게 나타납니다.
이런 경우에는 1분 정도 간격을 두고 hang 덤프를 받아 분석해 보면 대기하고 요청들의 병목 현상을 확인할 수 있습니다. 병목의 원인으로는 다른 서버로부터 응답을 받지 못한 경우가 많습니다.
The following threads in w3wp.exe__DefaultAppPool__PID__5596__Date__06_09_2006__Time_09_40_02AM__770__Manual Dump.dmp are waiting on data to be returned from another server via WinSock. The call to WinSock originated from dbnetlib!ConnectionRead+3b6 ( 28 29 30 32 33 34 35 49 61 ) 13.24% of threads blocked |
Script call stack for thread 39 running ASP page (Global.asa) Function Scope Line Of Code ---------------------------------------------------------------------------------------- ExecuteSQLReturnRS SET l_rsSet = p_conName.Execute(p_sQuery) Global Scope arrRelWord = ExecuteSQLReturnRS(m_dbConn, Sql) Global Scope Server.Execute(ItemPath) Script call stack for thread 41 running ASP page (Global.asa) Function Scope Line Of Code ---------------------------------------------------------------------------------------- Global Scope Set rs = DbCon_db3.Execute(sql) Global Scope Server.Execute(ItemPath) Script call stack for thread 47 running ASP page (Global.asa) Function Scope Line Of Code ---------------------------------------------------------------------------------------- getFileContent Set File = Fso.opentextfile(Path, 1, False, -2) Global Scope strArticleContent = getFileContent(server.mappath(ArticleFilePath)) Global Scope Server.Execute(ItemPath) |
다. 높은 CPU 사용
CPU가 불규칙하게 100을 사용하는 경우에는 문제가 발생하던 시점의 성능 카운터 로그오와 Hang 덤프가 필요합니다. 성능 카운터 로그에는 Thread 항목을 반드시 추가해서 잡으셔야 하며 가능한 1초 간격으로 받는 것이 좋습니다. 그리고 IIS hang 덤프를 받아 주셔야 하는데요, 가능하다면 1분 정도 간격을 두고 1번 정도 받는 것이 좋습니다.
ChildEBP RetAddr Args to Child 133ca634 77e7a243 00000000 133ca64c 77e5b5a8 NTDLL!ZwDelayExecution+0xb 133ca654 77e7a20e 00000000 00000000 6064bb7d KERNEL32!SleepEx+0x32 133ca660 6064bb7d 00000000 00000000 133cd7fc KERNEL32!Sleep+0xb WARNING: Stack unwind information not available. Following frames may be wrong. 133ca678 60b16421 60ba1620 133cd8ec 133cd978 oracore8!sltsima+0x4d 133cb7cc 604c8e51 00000000 00001001 133cc7fc oran8!niqname+0x51 133cd908 604b1371 02c37e60 00000008 133cd978 OraClient8!xaolog+0x34cd1 133cd93c 60429f37 0804156c 02c37e60 00000008 OraClient8!xaolog+0x1d1f1 133cd988 60401340 08041400 037e7318 02c37e60 OraClient8!kpuatch+0x2f7 133cd9ac 02bf59ab 08041400 037e7318 02c37e60 OraClient8!OCIServerAttach+0x20 133cd9c8 04c3432f 08041400 037e7318 02c37e60 oci!OCIServerAttach+0x2b ffffffff 00000000 00000000 00000000 00000000 sqora32!fLoginDlg+0x10b6f |
성능 카운터 로그의 Thread 항목을 받아야 하는 이유는 문제의 프로세스에서 어떤 쓰레드가 CPU을 가장 많이 사용하는지를 확인하기 위해서 입니다. 이렇게 확인된 쓰레드번호를 IIS hang 덤프에서 확인해 보면 어떤 작업을 하고 있었는지를 확인할 수 있습니다.
특히 ASP.NET과 관련하여 GC가 호출되면서 CPU가 100이 되는 경우가 많이 있습니다. 이런 경우에는 .NET Memory 항목을 확인해 보면 알 수 있는데요, .NET 프레임워크에 대한 패치가 모두 되어 있는지를 먼저 확인해야 합니다.
라. 높은 메모리 사용
메모리 사용이 높은 문제가 발생했을 경우에는 문제가 ASP.NET에 있는냐 없느냐에 따라 접근하는 방법이 조금 다릅니다.
처음엔 어디서 이런 문제가 발생하는 지를 알 수 없으므로 메모리가 거의 한도에 도달했을 때의 성능 카운터 로그와 함께 IIS hang 덤프가 필요합니다. 분석 후 .NET 부분의 문제가 아니라면 DebugDiag응 이용하여 Memory Leak에 대한 덤프를 구성해야 합니다. Memory Leak에 대한 덤프는 메모리 사용을 추적하도록 하는 덤프입니다.
Memory Leak 덤프 구성 [문제가 발생하기 전..] 1. DebugDiag 다운로드 및 설치합니다. 2. IIS를 다시 시작한 다음(iisreset.exe), 해당 웹 사이트에 접근하여 w3wp.exe 프로세스가 시작되도록 합니다. [옵션 구성] 1. DebugDiag의 Tools에서 Options & Settings를 선택합니다. 2. Preferences 탭에서 User service mode to overcome terminal server limitations (not persisted)를 체크합니다. (권장 옵션) Enable raw debugger logs. Includes debug output and engine messages를 체크합니다. 3. Performance Log 탭에서 Enable Performance Counter Data Logging를 선택하고, Data Sampling Interval 간격을 확인합니다. [DebugDiag 구성1] 1. DebugDiag를 시작한 다음, processes 탭에서 모니터링할 w3wp.exe의 프로세스의 PID를 알아둡니다. 2. Select Rule Type 창에서 Memory and Handle Leak을 선택합니다. 이 창이 보이지 않으면 Add Rule… 버튼을 클릭합니다. 3. Select Target 창에서 w3wp.exe를 선택합니다. 4. Configure Tracking Duration 창에서 Tracking time이 60인 것을 확인합니다. Memory Leak이 발생하는 충분한 기간을 입력해 주세요.(180분 권장) 5. Select Dump Location And Rule Name 창에서 rule name과 Userdump Location을 확인합니다. 6. Rule Completed 창에서 activate the rule now를 선택합니다. [문제 발생 후..] 문제가 발생하면 DebugDiag는 자동으로 덤프를 받습니다. DebugDiag 창에서는 Userdump Count 값이 증가하게 됩니다. 덤프가 받아 졌으면 DebugDiag가 설치된 경로의 Logs 폴더 전체를 압축해 보내주시기 바랍니다. |
마. 많은 이슈들
인증과 관련된 문제가 Hangking과 관련된 문제 등 범주화 하기는 어려운 여러가지 문제가 있습니다. 이런 문제들도 기본적인 자료를 바탕으로 분석해 보면 문제 해결을 위해 어떤 자료를 추가적으로 수집해야할지를 알려 주는 경우가 많습니다.
- MPSReports
- IIS Metabase
- IIS Log
- HTTPERR Log
4. DebugDiag 사용법
DebugDiag을 이용하여 자료를 수집하고 분석하는 방법을 설명드리기 전에 DebugDiag의 구조에 대해서 먼저 말씀 드리겠습니다. DebugDiag는 4개의 주요 부분으로 구성되어 있습니다.
DbgSvc.exe
이 프로세스는 서비스에 등록되어 동작하며, 디버거를 덤프를 받고자 하는 프로세스에 붙이거나, 웹서버가 살아 있는지 모니텅하는 역할 등을 수행하게 됩니다. 특히 이전 ADPlus와 비교하여 터미널로 작업했을 경우에도 콘솔에서 작업한 것처럼 디버거를 붙일 수 있기 때문에 매우 편리해 졌습니다.
DbgHost.exe
실질적으로 디버거입니다. 만약 w3wp.exe 프로세스가 10개 정도 실행되고 있는 환경에서는 10개의 DbgHost.exe 프로세스가 생성되게 됩니다.
DebugDiag.exe
디버깅을 걸 수 있는 사용자용 프로그램입니다. 이 프로그램은 DbgSvc.exe와 DbgHost.exe 프로세스에 작업을 편하게 할 수 있도록 도와주는 프로그램입니다. 따라서 예전의 ADPlus 처럼 작업 후 창을 한다고 해서 해당 프로세스가 따라 종료되거나 하는 현상은 발생하지 않습니다.
LeakTrack.dll
메모리 누수가 있을 경우 해당 프로세스에 삽입되어 사용하는 모듈입니다.
가. User Interface
(1) Rules 탭
이 탭에서는 문제 유형에 따른 덤프를 구성하고 편집하고 삭제하는 곳입니다. Step by Step으로 덤프를 구성하게 됩니다.
(2) Advanced Analysis 탭
앞서 받은 덤프를 여기서 분석해 보실 수 있습니다. 분석 결과는 htm 문서로 리포팅됩니다.
(3) Processes 탭
W3wp.exe 프로세스의 Web application pool을 확인할 수 있으며, 수동으로 덤프를 받을 때 사용하게 됩니다.
(4) Tools 메뉴
Tools 메뉴에서는 Event Logs, IIS Logs, HTTPERR Logs 등의 자료를 수집할 수 있으며 특히 IIS Metabase 자료를 수집할 수 있습니다. 그리고 수동으로 IIS Hang 덤프를 받을 때도 Tools 메뉴를 사용하게 됩니다.
(5) Options & Settings 메뉴
여기서는 세부적인 분석을 위한 심볼 경오를 지정할 수 있으며, 간단하게 성능 로그도 수집할 수 있습니다.
나. DebugDiag 덤프 구성
(1) crash 덤프 구성
Crash 덤프를 받는 구성을 하기 위하여 Add Rule… 버튼을 클릭하면 마법사가 시작되는데요, Crash를 선택하고 다음을 클릭합니다.
덤프를 받을 프로세스를 지정하는 곳인데요, 일반적으로 All IIS related process를 선택합니다. 여기에는 inetinfo.exe, w3wp.exe 그리고 dllhost.exe 프로세스가 포함됩니다.
여기서는 덤프를 받는 횟수와 고급 덤프 구성을 하실 수 있는데요, First Chance Exceptions에 대하여 Mini Userdump을 받아 두시는 것이 분석에 도움이 될 경우가 많습니다.
덤프의 위치를 지정하실 수 있습니다. 기본경로는 DebugDiag가 설치된 경우의 Logs 폴더 아래 생성됩니다.
(2) pageheap 덤프 구성
pageheap은 crash가 발생한 프로세스의 heap이 손상되었을 경우에 설정하는 덤프 입니다. 먼저 A specific process를 선택합니다.
문제가 되는 프로세스를 선택합니다.
PageHeap Flags를 클릭한 다음, Normal 또는 Full PageHeap을 선택합니다. 권장은 Full입니다만, PageHeap 구성자체가 서버에 많은 부하를 주게 되므로 신중히 선택하셔야 합니다.
그리고 PageHeap을 선택하신 다음에는 서버를 재시작하거나 IISRESET을 해 주셔야 합니다. 권장은 서버재시작입니다.
(3) Hang 덤프 구성
Hang 덤프는 일반적으로 문제 시점에 수동으로 받는 것이 가장 좋습니다만, 그렇지 못할 경우를 대비해서 다음과 같이 구성하실 수 있습니다. 먼저 IIS Hang을 선택합니다.
모니터링할 URL을 입력합니다. 가장 많이 호출되면서 응답이 없는 것을 쉽게 느낄 수 있는 페이지를 입력합니다.
Hang 증상이 감지되었을 경우에 받아야할 덤프의 범위를 지정합니다. All IIS related process를 일반적으로 선택합니다.
(4) Memory Leak 덤프 구성
메모리 누수가 있다고 판단되면 Memory Leak 덤프를 받을 수 있습니다.
해당 프로세스를 정확히 선택해 주셔야 합니다.
모니터링할 시간을 입력하는데요, 메모리 사용이 높으면 w3wp.exe 프로세스가 자동으로 재시작되므로 적절한 시간을 입력해 주셔야 합니다.
5. IIS 관련 사이트
Internet Information Services
http://www.microsoft.com/WindowsServer2003/iis/default.mspx
Microsoft Product Support's Reporting Tools
Log Parser 2.2
IIS 상태 코드
http://support.microsoft.com/?id=318380
HTTP API의 오류 로깅
http://support.microsoft.com/?id=820729
How to View HTTP Data Frames Using Network Monitor
http://support.microsoft.com/?id=252876
IIS의 시스템 모니터에서 카운터 로그를 사용하여 웹 서버의 성능을 모니터링하는 방법
http://support.microsoft.com/?id=313064
IIS Diagnostics Toolkit
Install Debugging Tools for Windows 32-bit Version
http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx
Filemon
http://www.sysinternals.com/ntw2k/source/filemon.shtml
Regmon
http://www.sysinternals.com/Utilities/Regmon.html
Internet Information Services (IIS) 6.0 Resource Kit Tools
관련자료
http://www.asrgo.com/index.php?document_srl=116268&mid=faq
댓글목록
등록된 댓글이 없습니다.