Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 1개 있습니다.)
(시리즈 글이 6개 있습니다.)
.NET Framework: 174. 작업자 프로세스(w3wp.exe)가 재시작되는 시점을 알 수 있는 방법
; https://www.sysnet.pe.kr/2/0/841

.NET Framework: 447. w3wp.exe AppPool 재생(recycle)하는 방법 정리
; https://www.sysnet.pe.kr/2/0/1704

개발 환경 구성: 246. IIS 작업자 프로세스의 20분 자동 재생(Recycle)을 끄는 방법
; https://www.sysnet.pe.kr/2/0/1774

.NET Framework: 643. 작업자 프로세스(w3wp.exe)가 재시작되는 시점을 알 수 있는 방법 - 두 번째 이야기
; https://www.sysnet.pe.kr/2/0/11145

개발 환경 구성: 702. IIS - AppPool의 "Disable Overlapped Recycle" 옵션
; https://www.sysnet.pe.kr/2/0/13514

닷넷: 2196. IIS - AppPool의 "Disable Overlapped Recycle" 옵션의 부작용
; https://www.sysnet.pe.kr/2/0/13516




작업자 프로세스(w3wp.exe)가 재시작되는 시점을 알 수 있는 방법 - 두 번째 이야기

예전 글에 이어,

작업자 프로세스(w3wp.exe)가 재시작되는 시점을 알 수 있는 방법
; https://www.sysnet.pe.kr/2/0/841

아래의 글은 Global.asax의 Application_End 이벤트 핸들러에서 Recycle의 원인을 알아내는 방법을 설명합니다.

Logging ASP.NET Application Shutdown Events
; https://weblogs.asp.net/scottgu/433194

정리하면, Application_End가 호출되는 시점에 HttpRuntime 객체에 저장된 _shutDownMessage와 _shutDownStack 필드의 값을 .NET Reflection을 이용해 읽어내는 것입니다.

protected void Application_End(object sender, EventArgs e)
{
    HttpRuntime runtime = (HttpRuntime)typeof(System.Web.HttpRuntime).InvokeMember("_theRuntime",
        BindingFlags.NonPublic | BindingFlags.Static | BindingFlags.GetField, null, null, null);

    if (runtime == null)
        return;

    string shutDownMessage = (string)runtime.GetType().InvokeMember("_shutDownMessage",
        BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.GetField, null, runtime, null);

    string shutDownStack = (string)runtime.GetType().InvokeMember("_shutDownStack",
        BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.GetField, null, runtime, null);

    System.Diagnostics.Trace.WriteLine(String.Format("\r\n\r\n_shutDownMessage={0}\r\n\r\n_shutDownStack={1}",
        shutDownMessage, shutDownStack));
}

위의 예제는 ASP.NET 2.0을 대상으로 하지만, .NET 4.6.1에서도 여전히 잘 동작합니다. 가령, web.config을 변경한 경우 .NET 2.0 기반에서는 다음과 같이 출력 값이 나오고,

_shutDownMessage=CONFIG change
HostingEnvironment initiated shutdown
CONFIG change
CONFIG change
HostingEnvironment caused shutdown

_shutDownStack=   at System.Environment.get_StackTrace()
   at System.Web.Hosting.HostingEnvironment.InitiateShutdownInternal()
   at System.Web.Hosting.HostingEnvironment.InitiateShutdown()
   at System.Web.HttpRuntime.ShutdownAppDomain(String stackTrace)
   at System.Web.Configuration.HttpConfigurationSystem.OnConfigurationChanged(Object sender, InternalConfigEventArgs e)
   at System.Configuration.BaseConfigurationRecord.OnStreamChanged(String streamname)

.NET 4.6.1에서는 이렇게 나옵니다.

_shutDownMessage=IIS configuration change
CONFIG change
HostingEnvironment initiated shutdown
CONFIG change
CONFIG change
HostingEnvironment caused shutdown

_shutDownStack=   at System.Environment.GetStackTrace(Exception e, Boolean needFileInfo)
   at System.Environment.get_StackTrace()
   at System.Web.Hosting.HostingEnvironment.InitiateShutdownInternal()
   at System.Web.Hosting.HostingEnvironment.InitiateShutdownWithoutDemand()
   at System.Web.Hosting.PipelineRuntime.StopProcessing()

그런데, Application_End는 Global.asax 이외의 클래스에서는 구독하는 것이 안됩니다. 왜냐하면, End 이벤트가 HttpApplication 객체에는 없기 때문입니다. 따라서 외부 DLL에서 참조하고 싶다면 다음과 같이 HttpContext를 이용해 Disposed 이벤트를 구독해야 합니다.

HttpContext.Current.ApplicationInstance.Disposed += ApplicationInstance_Disposed;

Application_End와 Disposed가 이벤트가 발생하는 시점을 잡아 각각의 Call stack을 확인하면 그 이유를 알 수 있습니다.

// Application_End 호출 시점의 Call stack

>    Test.dll!WebSiteTest.Global.Application_End(object sender, System.EventArgs e) Line 430 C#
    [Native to Managed Transition]  
    System.Web.dll!System.Web.HttpApplication.InvokeMethodWithAssert(System.Reflection.MethodInfo method, int paramCount, object eventSource, System.EventArgs eventArgs) + 0x7a bytes  
    System.Web.dll!System.Web.HttpApplication.ProcessSpecialRequest(System.Web.HttpContext context, System.Reflection.MethodInfo method, int paramCount, object eventSource, System.EventArgs eventArgs, System.Web.SessionState.HttpSessionState session) + 0x126 bytes    
    System.Web.dll!System.Web.HttpApplicationFactory.FireApplicationOnEnd() + 0x6b bytes    
    System.Web.dll!System.Web.HttpApplicationFactory.Dispose() + 0x80 bytes 
    System.Web.dll!System.Web.HttpRuntime.Dispose() + 0x158 bytes   
    System.Web.dll!System.Web.HttpRuntime.ReleaseResourcesAndUnloadAppDomain(object state) + 0x3d bytes 
    mscorlib.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) + 0x15e bytes 
    mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) + 0x17 bytes  
    mscorlib.dll!System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem() + 0x70 bytes 
    mscorlib.dll!System.Threading.ThreadPoolWorkQueue.Dispatch() + 0x160 bytes  
    [Native to Managed Transition]  
    [Appdomain Transition]  
    [Native to Managed Transition]  

// Global_Disposed 호출 시점의 Call stack

>    Test.dll!WebSiteTest.Global.Global_Disposed(object sender, System.EventArgs e) Line 425 C#
    System.Web.dll!System.Web.HttpApplication.Dispose() + 0x9f bytes    
    System.Web.dll!System.Web.HttpApplication.DisposeInternal() + 0x30 bytes    
    System.Web.dll!System.Web.HttpApplicationFactory.DisposeHttpApplicationInstances(System.Collections.Stack freeList, ref int numFreeInstances) + 0xf6 bytes  
    System.Web.dll!System.Web.HttpApplicationFactory.Dispose() + 0xd2 bytes 
    System.Web.dll!System.Web.HttpRuntime.Dispose() + 0x158 bytes   
    System.Web.dll!System.Web.HttpRuntime.ReleaseResourcesAndUnloadAppDomain(object state) + 0x3d bytes 
    mscorlib.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) + 0x15e bytes 
    mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) + 0x17 bytes  
    mscorlib.dll!System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem() + 0x70 bytes 
    mscorlib.dll!System.Threading.ThreadPoolWorkQueue.Dispatch() + 0x160 bytes  
    [Native to Managed Transition]  
    [Appdomain Transition]  
    [Native to Managed Transition]  

어차피 HttpRuntime.Dispose 메서드를 시작으로 Application_End가 호출된 후 Disposed 이벤트가 발생하기 때문에 HttpRuntime의 _shutDownMessage와 _shutDownStack 필드 값은 동일합니다.

(첨부 파일은 이 글의 예제 코드를 포함합니다.)




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 2/16/2017]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 



2017-02-16 10시00분
[ryujh] 안녕하세요.

본문 중 CONFIG change 와 같이 재시작의 원인이 나외있는데 그 밖에도 Recompile 의 회수(횟수?)가 초과도 원인입니다.

Recompile 이라면 가상경로에서 파일 수정으로 적용하여 발생할 수 있습니다. 쓰기 작업을 가상경로에서 하지 않고 다른 경로에 할 수 있다면 재시작이 적어지니 안정적으로 서비스가 가능할 것입니다.
[guest]
2017-02-22 02시29분
.NET 소스 코드에 Recycle에 대한 이유 몇 가지가 나옵니다.

ApplicationShutdownReason Enum
; https://referencesource.microsoft.com/#system.web/HttpRuntime.cs,4d404925e0f99eb1,references
정성태
2017-02-24 08시04분
[ryujh] 안녕하세요.

이유가 무려 15가지나 되는군요. 15가지 이유 중에 하나로 어플리케이션이 shutdown 될 수 있다는 것인데 안정적인 웹서비스가 어려운지 이제 알겠습니다.

그래서 요즘에는 웹에서 하는 로직을 일부 콘솔프로그램에서 담당하도록 작업 중 입니다.
[guest]
2017-02-25 02시27분
ryujh님, shutdown 될 수 있기는 한데 그래서 더 '안정적인' 경우가 많습니다. ^^ 그리고 recycle 과정 자체가 서비스를 중단 없이 하기 때문에 in-memory Session 같은 것 등을 쓰지 않는 한 서비스 장애로 이어지는 경우는 없습니다.
정성태

... 46  47  48  49  50  51  52  53  54  55  56  57  [58]  59  60  ...
NoWriterDateCnt.TitleFile(s)
12173정성태3/7/202011082개발 환경 구성: 475. docker - SQL Server 2019 컨테이너 실행 [1]
12172정성태3/7/202015961개발 환경 구성: 474. docker - container에서 root 권한 명령어 실행(sudo)
12171정성태3/6/202010883VS.NET IDE: 143. Visual Studio - ASP.NET Core Web Application의 "Enable Docker Support" 옵션으로 달라지는 점 [1]
12170정성태3/6/20209521오류 유형: 599. "Docker Desktop is switching..." 메시지와 DockerDesktopVM CPU 소비 현상
12169정성태3/5/202011558개발 환경 구성: 473. Windows nanoserver에 대한 docker pull의 태그 사용 [1]
12168정성태3/5/202012236개발 환경 구성: 472. 윈도우 환경에서의 dockerd.exe("Docker Engine" 서비스)가 Linux의 것과 다른 점
12167정성태3/5/202011474개발 환경 구성: 471. C# - 닷넷 응용 프로그램에서 DB2 Express-C 데이터베이스 사용 (3) - ibmcom/db2express-c 컨테이너 사용
12166정성태3/4/202011134개발 환경 구성: 470. Windows Server 컨테이너 - DockerMsftProvider 모듈을 이용한 docker 설치
12165정성태3/2/202010812.NET Framework: 900. 실행 시에 메서드 가로채기 - CLR Injection: Runtime Method Replacer 개선 - 네 번째 이야기(Monitor.Enter 후킹)파일 다운로드1
12164정성태2/29/202011693오류 유형: 598. Surface Pro 6 - Windows Hello Face Software Device가 인식이 안 되는 문제
12163정성태2/27/202010104.NET Framework: 899. 익명 함수를 가리키는 delegate 필드에 대한 직렬화 문제
12162정성태2/26/202012868디버깅 기술: 166. C#에서 만든 COM 객체를 C/C++로 P/Invoke Interop 시 메모리 누수(Memory Leak) 발생 [6]파일 다운로드2
12161정성태2/26/20209539오류 유형: 597. manifest - The value "x64" of attribute "processorArchitecture" in element "assemblyIdentity" is invalid.
12160정성태2/26/202010219개발 환경 구성: 469. Reg-free COM 개체 사용을 위한 manifest 파일 생성 도구 - COMRegFreeManifest
12159정성태2/26/20208421오류 유형: 596. Visual Studio - The project needs to include ATL support
12158정성태2/25/202010235디버깅 기술: 165. C# - Marshal.GetIUnknownForObject/GetIDispatchForObject 사용 시 메모리 누수(Memory Leak) 발생파일 다운로드1
12157정성태2/25/202010115디버깅 기술: 164. C# - Marshal.GetNativeVariantForObject 사용 시 메모리 누수(Memory Leak) 발생 및 해결 방법파일 다운로드1
12156정성태2/25/20209450오류 유형: 595. LINK : warning LNK4098: defaultlib 'nafxcw.lib' conflicts with use of other libs; use /NODEFAULTLIB:library
12155정성태2/25/20208757오류 유형: 594. Warning NU1701 - This package may not be fully compatible with your project
12154정성태2/25/20208614오류 유형: 593. warning LNK4070: /OUT:... directive in .EXP differs from output filename
12153정성태2/23/202011275.NET Framework: 898. Trampoline을 이용한 후킹의 한계파일 다운로드1
12152정성태2/23/202010999.NET Framework: 897. 실행 시에 메서드 가로채기 - CLR Injection: Runtime Method Replacer 개선 - 세 번째 이야기(Trampoline 후킹)파일 다운로드1
12151정성태2/22/202011540.NET Framework: 896. C# - Win32 API를 Trampoline 기법을 이용해 C# 메서드로 가로채는 방법 - 두 번째 이야기 (원본 함수 호출)파일 다운로드1
12150정성태2/21/202011362.NET Framework: 895. C# - Win32 API를 Trampoline 기법을 이용해 C# 메서드로 가로채는 방법 [1]파일 다운로드1
12149정성태2/20/202011108.NET Framework: 894. eBEST C# XingAPI 래퍼 - 연속 조회 처리 방법 [1]
12148정성태2/19/202012324디버깅 기술: 163. x64 환경에서 구현하는 다양한 Trampoline 기법 [1]
... 46  47  48  49  50  51  52  53  54  55  56  57  [58]  59  60  ...