Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 1개 있습니다.)
(시리즈 글이 7개 있습니다.)
.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

닷넷: 2274. IIS - (프로세스 종료 없는) AppDomain Recycle
; https://www.sysnet.pe.kr/2/0/13672




작업자 프로세스(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 필드 값은 동일합니다.

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




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 7/10/2024]

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)
12537정성태2/11/202119353.NET Framework: 1022. UI 요소의 접근은 반드시 그 UI를 만든 스레드에서! - 두 번째 이야기 [2]
12536정성태2/9/202118200개발 환경 구성: 542. BDP(Bandwidth-delay product)와 TCP Receive Window
12535정성태2/9/202117273개발 환경 구성: 541. Wireshark로 확인하는 LSO(Large Send Offload), RSC(Receive Segment Coalescing) 옵션
12534정성태2/8/202117789개발 환경 구성: 540. Wireshark + C/C++로 확인하는 TCP 연결에서의 closesocket 동작 [1]파일 다운로드1
12533정성태2/8/202116794개발 환경 구성: 539. Wireshark + C/C++로 확인하는 TCP 연결에서의 shutdown 동작파일 다운로드1
12532정성태2/6/202117993개발 환경 구성: 538. Wireshark + C#으로 확인하는 ReceiveBufferSize(SO_RCVBUF), SendBufferSize(SO_SNDBUF) [3]
12531정성태2/5/202116773개발 환경 구성: 537. Wireshark + C#으로 확인하는 PSH flag와 Nagle 알고리듬파일 다운로드1
12530정성태2/4/202120595개발 환경 구성: 536. Wireshark + C#으로 확인하는 TCP 통신의 Receive Window
12529정성태2/4/202118459개발 환경 구성: 535. Wireshark + C#으로 확인하는 TCP 통신의 MIN RTO [1]
12528정성태2/1/202118056개발 환경 구성: 534. Wireshark + C#으로 확인하는 TCP 통신의 MSS(Maximum Segment Size) - 윈도우 환경
12527정성태2/1/202118145개발 환경 구성: 533. Wireshark + C#으로 확인하는 TCP 통신의 MSS(Maximum Segment Size) - 리눅스 환경파일 다운로드1
12526정성태2/1/202114944개발 환경 구성: 532. Azure Devops의 파이프라인 빌드 시 snk 파일 다루는 방법 - Secure file
12525정성태2/1/202113926개발 환경 구성: 531. Azure Devops - 파이프라인 실행 시 빌드 이벤트를 생략하는 방법
12524정성태1/31/202115126개발 환경 구성: 530. 기존 github 프로젝트를 Azure Devops의 빌드 Pipeline에 연결하는 방법 [1]
12523정성태1/31/202116053개발 환경 구성: 529. 기존 github 프로젝트를 Azure Devops의 Board에 연결하는 방법
12522정성태1/31/202118245개발 환경 구성: 528. 오라클 클라우드의 리눅스 VM - 9000 MTU Jumbo Frame 테스트
12521정성태1/31/202117330개발 환경 구성: 527. 이더넷(Ethernet) 환경의 TCP 통신에서 MSS(Maximum Segment Size) 확인 [1]
12520정성태1/30/202116092개발 환경 구성: 526. 오라클 클라우드의 VM에 ping ICMP 여는 방법
12519정성태1/30/202114815개발 환경 구성: 525. 오라클 클라우드의 VM을 외부에서 접근하기 위해 포트 여는 방법
12518정성태1/30/202132911Linux: 37. Ubuntu에 Wireshark 설치 [2]
12517정성태1/30/202120620Linux: 36. 윈도우 클라이언트에서 X2Go를 이용한 원격 리눅스의 GUI 접속 - 우분투 20.04
12516정성태1/29/202117099Windows: 188. Windows - TCP default template 설정 방법
12515정성태1/28/202118749웹: 41. Microsoft Edge - localhost에 대해 http 접근 시 무조건 https로 바뀌는 문제 [3]
12514정성태1/28/202118887.NET Framework: 1021. C# - 일렉트론 닷넷(Electron.NET) 소개 [1]파일 다운로드1
12513정성태1/28/202116045오류 유형: 698. electronize - User Profile 디렉터리에 공백 문자가 있는 경우 빌드가 실패하는 문제 [1]
12512정성태1/28/202116434오류 유형: 697. The program can't start because VCRUNTIME140.dll is missing from your computer. Try reinstalling the program to fix this problem.
... 46  47  48  49  50  51  52  53  54  55  [56]  57  58  59  60  ...