Cloud Services 가상 머신에서 애플리케이션 풀 충돌 문제 해결
이 문서에서는 Microsoft Azure Cloud Services의 VM(가상 머신)에서 애플리케이션 풀 충돌을 해결하는 방법을 설명합니다. 애플리케이션 풀이 충돌하면 애플리케이션의 응답이 중지됩니다.
1단계: 애플리케이션 풀을 제공하는 프로세스의 오류 확인
이벤트 뷰어 콘솔 트리에서 Windows 로그>시스템을 선택하면 다음 이벤트 중 하나가 표시될 수 있습니다.
애플리케이션 풀 '%1'을(를) 처리하는 프로세스에서 Windows 프로세스 정품 인증 서비스와의 심각한 통신 오류가 발생했습니다. 프로세스 ID가 '%2'였습니다. 데이터 필드에 오류 번호가 포함됩니다.
애플리케이션 풀 '%1'을(를) 처리하는 프로세스가 예기치 않게 종료되었습니다. 프로세스 ID가 '%2'였습니다. 프로세스 종료 코드가 '%3'이었습니다.
이러한 이벤트는 애플리케이션 풀 충돌을 명확하게 나타냅니다. 애플리케이션 내에서 문제가 발생하여 애플리케이션 풀을 종료해야 했습니다. 애플리케이션 풀이 종료되면 해당 w3wp.exe 프로세스도 종료됩니다. w3wp.exe 프로세스 내에 저장한 캐시 기반 또는 세션 기반 정보는 지워집니다.
2단계: 관련 프로세스 오류로 인해 애플리케이션 풀이 자동으로 비활성화되었는지 확인
이상적으로 애플리케이션 풀이 충돌하면 들어오는 요청을 적용하기 위해 새 w3wp.exe 프로세스가 자동으로 생성됩니다. 그러나 애플리케이션 풀이 5분 이내에 5회 이상 충돌하는 경우 애플리케이션 풀은 중지된 상태로 전환됩니다. 애플리케이션 풀을 시작하고 실행하려면 애플리케이션 풀을 수동으로 다시 시작해야 합니다. 비슷한 상황이 발생하면 이벤트 뷰어 시스템 로그에서 다음 이벤트를 확인할 수 있습니다.
애플리케이션 풀 '%1'은(는) 해당 애플리케이션 풀을 제공하는 프로세스의 일련의 오류로 인해 자동으로 비활성화됩니다.
빠른 실패 보호 섹션 아래의 해당 애플리케이션 풀의 고급 설정 대화 상자에서 이러한 설정을 구성할 수 있습니다. Enabled 속성의 기본값은 True입니다. Enabled 속성이 True이면 특정 시간 내에 실패 제한에 도달한 후 애플리케이션 풀이 중지됩니다. 실패 한도는 최대 실패 속성으로 표시됩니다. 이 속성의 기본값 은 5입니다. 시간 범위는 실패 간격(분) 속성으로 표시됩니다. 이 속성은 기본값도 5입니다.
3단계: w3wp.exe 프로세스 덤프 파일 캡처
애플리케이션이 크래시된 것을 확인한 후 크래시가 발생한 이유를 정확히 확인합니다. 종료되기 직전에 w3wp.exe 프로세스의 덤프 파일을 캡처해야 합니다. 이 파일을 캡처하는 방법에는 여러 가지가 있습니다. WER(Windows 오류 보고), ProcDump 및 DebugDiag를 설정하여 크래시 덤프 파일을 캡처할 수 있습니다. 이 문서에서는 데이터를 캡처하는 DebugDiag 메서드에 대해서만 설명합니다.
DebugDiag를 다운로드하고 설치하려면 다음 단계를 수행합니다.
디버그 진단 도구 v2 사이트로 이동한 다음 다운로드를 선택합니다.
원하는 다운로드를 선택하려면 컴퓨터 아키텍처에 적합한 MSI(Microsoft Windows Installer) 파일 버전을 선택한 다음, 다음을 선택합니다.
다운로드한 파일을 엽니다. 설치 마법사에서 기본 옵션을 적용한 다음 앱 설치를 완료합니다.
DebugDiag 2 컬렉션 애플리케이션을 설정하려면 다음 단계를 수행합니다.
시작을 선택하고 DebugDiag 2 컬렉션을 입력한 다음 결과 목록에서 새로 설치된 앱을 엽니다.
규칙 유형 선택 대화 상자에서 크래시 옵션을 선택한 다음, 다음을 선택합니다.
대상 유형 선택 대화 상자에서 A 특정 IIS 웹 애플리케이션 풀 옵션을 선택한 다음, 다음을 선택합니다.
대상 선택 대화 상자에서 충돌하는 특정 애플리케이션 풀을 선택한 다음, 다음을 선택합니다. IIS(인터넷 정보 서비스) 관리가 설치되지 않고 애플리케이션 풀이 나열되지 않음을 나타내는 창이 열리면 확인을 선택한 다음 애플리케이션 이름을 수동으로 입력합니다.
고급 구성(선택 사항) 대화 상자에서 중단점 중단점 추가를>선택합니다.
다음을 선택하여 새 중단점을 만든 다음 확인을 선택합니다.
필드 설명 값 오프셋 식 캡처할 프로세스 Ntdll!ZwTerminateProcess 작업 유형 캡처된 덤프의 유형 전체 userdump 작업 제한 캡처할 덤프 수 10 중단점 구성 대화 상자에서 새 중단점 식 항목이 표시되는지 확인합니다. 저장 및 닫기를 선택하여 고급 구성(선택 사항) 대화 상자로 돌아가고 다음을 선택하여 중단점을 활성화합니다.
덤프 위치 및 규칙 이름 선택(선택 사항) 대화 상자에서 규칙 이름을 입력한 다음, 필요한 경우 충분한 사용 가능한 디스크 공간이 있는 드라이브 및 디렉터리로 Userdump 위치를 변경합니다. (각 덤프 파일의 크기는 메모리의 w3wp.exe 프로세스에서 사용하는 것과 일치합니다.)
다음을 선택합니다.
규칙을 활성화하려면 마침을 선택합니다.
이제 크래시 규칙이 활성 상태이고 Userdump 개수가 0입니다. 문제가 발생하면 덤프 수가 즉시 증가하고 해당 덤프 파일이 생성됩니다.
참고 항목
애플리케이션 풀의 일반적인 재활용은 덤프 파일을 트리거할 수도 있습니다. 이는 재활용할 때 애플리케이션 풀의 해당 W3WP.EXE 프로세스 ID(PID)가 변경되기 때문에 발생합니다. 그러면 덤프 파일이 생성됩니다. 이 파일은 가양성입니다. 따라서 애플리케이션 풀 충돌을 분석하는 데 도움이 되지 않습니다. userdump 수의 증가가 표시될 때마다 이벤트 로그를 확인하여 예상 크래시 이벤트가 발생했는지 확인합니다. 이벤트가 예상대로인 경우 캡처된 덤프가 올바릅니다.
4단계: w3wp.exe 프로세스 덤프 파일 분석
덤프 파일이 캡처되면 DebugDiag 시작>2 분석을 열 수 있습니다. 이 애플리케이션을 사용하면 캡처된 크래시 덤프 파일을 분석할 수 있습니다.
기호 경로가 올바르게 설정되어 있는지 확인합니다. 이는 두 부분으로 구성된 프로세스입니다. DebugDiag 2 분석에서 설정(기어 아이콘)을 선택합니다. 분석에 사용할 기호 검색 경로 아래에서 _NT_SYMBOL_PATH 및 Microsoft 공용 기호 서버가 선택되어 있는지 확인합니다.
DebugDiag 2 컬렉션을 다시 열고 도구>옵션 및 설정을 선택합니다. 그런 다음 옵션 및 설정 대화 상자에서 디버깅을 위한 기호 검색 경로(예: 충돌 규칙) 상자가 srv*c:\symcache*https://msdl.microsoft.com/download/symbols로 설정되어 있는지 확인합니다. 이 경로로 인해 DebugDiag는 필요에 따라 Microsoft 공용 기호 서버에서 기호를 다운로드한 다음 c:\symcache 디렉터리에 저장합니다.
기호 경로 설정을 변경하거나 확인한 후 캡처된 덤프 파일을 분석할 수 있습니다. 분석을 시작하려면 DebugDiag 2 분석으로 돌아가서 덤프 파일의 이름을 두 번 클릭합니다. 보고서가 생성되면 브라우저에서 보고서를 열고 중단점 식을 트리거한 스레드의 호출 스택을 이해할 수 있습니다. 맨 아래에서 위로 호출 스택을 읽은 다음 애플리케이션 풀이 충돌하도록 트리거한 메서드 또는 구성 요소를 결정합니다. 정확한 예외 호출 스택을 찾을 수 없는 경우 동일한 덤프 파일 분석에서 .NET 호출 스택을 자세히 살펴봅니다.
5단계: w3wp.exe 또는 WaWorkerHost.exe 프로세스에서 처리되지 않은 예외 확인
또한 w3wp.exe 또는 WaWorkerHost.exe 프로세스가 중지된 처리되지 않은 예외를 확인하려면 처리되지 않은 예외로 인해 ASP가 발생하는 것을 참조하세요. .NET Framework에서 예기치 않게 종료할 NET 기반 애플리케이션입니다.
타사 정보 고지 사항
이 문서에 나와 있는 다른 공급업체 제품은 Microsoft와 무관한 회사에서 제조한 것입니다. Microsoft는 이들 제품의 성능이나 안정성에 관하여 명시적이든 묵시적이든 어떠한 보증도 하지 않습니다.
도움을 요청하십시오.
질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.