Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일

실제 사례를 통해 Debug Diagnostics 도구가 생성한 닷넷 웹 응용 프로그램의 성능 장애 보고서 설명

최근에 고객사 덤프 분석을 하면서 의외로 "Debug Diagnostic" 도구의 결과물에 대해 너무 어렵다는 선입견을 보게 되었습니다.

DebugDiag 1.1을 사용한 덤프 분석
; https://www.sysnet.pe.kr/2/0/1026

Debug Diagnostic Tool v2 Update 3
; https://www.microsoft.com/en-us/download/details.aspx?id=58210

그런데, 실제로 사용해서 찬찬히 뜯어 보시면 충분히 일반적으로 인식할 수 있는 수준입니다. 여러분의 이해를 돕기 위해 이 글의 첨부 파일에 DebugDiag가 분석을 완료한 mht 출력 파일을 하나 올렸으니 그걸 보면서 설명해 보겠습니다. (실제 장애가 발생한 시점에 뜬 고객사 사례인데, 단지 메서드 등을 모두 TestWebApp이라든가 하는 식의 이름으로 바꾼 것입니다.)

dotnet_2_CrashHangAnalysis.mht
; https://www.sysnet.pe.kr/bbs/DownloadAttachment.aspx?fid=1513&boardid=331301885

위의 파일을 열어서 보면 초기에 다음과 같은 내용을 볼 수 있습니다.

windbg_es_hang_1.png

딱 봐도 문제가 있는 듯하죠? ^^ 어쨌든 메시지를 보면 610개의 스레드가 "System.Threading.Monitor.Wait"로 대기하고 있음을 알려주고 있습니다. 나열된 번호는 대기 중인 Thread의 ID 목록입니다.

그리고 내용을 좀 더 내려 보면 "Thread Report"가 나오고 그중에서 같은 thread call stack을 가진 것들만 연속으로 함께 나열된 후 해당 사실을 다음과 같이 알려줍니다.

windbg_es_hang_2.png

311 Threads (46% of all threads) have this same call stack.
Note: Grouping of identical threads can be disabled in the 'Preferences' tab of the Analysis Options

위의 메시지에 따라 이후 311개의 스레드가 같은 스레드 call stack을 갖고 있지만 개별 스레드마다 생성 시간 등은 다르므로 다음과 같이 그런 정보들만 다시 나열하고,

Thread 48 - System ID 18376

    Entry point   coreclr!Thread::intermediateThreadProc 
    Create time   2018-05-23 오후 10:04:41 
    Time spent in user mode   0 Days 00:00:46.531 
    Time spent in kernel mode   0 Days 00:00:00.953 

    This thread is waiting in System.Threading.Monitor.Wait


Thread 49 - System ID 32492

    Entry point   coreclr!Thread::intermediateThreadProc 
    Create time   2018-05-23 오후 10:07:13 
    Time spent in user mode   0 Days 00:00:39.625 
    Time spent in kernel mode   0 Days 00:00:01.015 

    This thread is waiting in System.Threading.Monitor.Wait

...[생략]...

311개 스레드 정보의 마지막에 해당하는 (dotnet_2_CrashHangAnalysis.mht의 경우 664번) 스레드가 나올 때 어떤 call stack을 동일하게 갖고 있는지 비로소 보여주게 됩니다.

windbg_es_hang_3.png

이 정도면 그냥 눈에 들어오죠? 위의 내용을 보면 가장 상단은 "System.Threading.ManualResetEventSlim.Wait"이지만 약간만 내려가도 ElasticSearch 관련 호출이 나오는 것에서 결국 ElasticSearch 호출로 인해, 즉 ElasticSearch 서버가 정상적으로 호출을 처리해주지 못해 311개의 스레드가 대기 중이라는 것을 알 수 있습니다.

이후의 Thread 분석 결과도 유사합니다. 처음 보고에서 610개의 스레드가 blocking 상태였는데 그중 311개는 위와 같은 상태이고, 다른 300개 정도의 스레드도 중간에 호출되는 업무 메서드가 달라서 callstack이 다른 것일 뿐 결국 상단에는 Elasticsearch.Net.HttpConnection.Request가 자리 잡고 있습니다.




어떠신가요? 덤프 분석이 (windbg로 하려면 어려운 듯하지만) Debug Diagnostics로 기본적인 분석 결과만 돌려봐도 응용 프로그램의 성능 문제를 파악하는 데 그다지 어려움이 없습니다.

따라서 앞으로는 문제가 발생했을 때, 무작정 iisreset 또는 recycle을 하지 말고 그전에 덤프 파일을 생성해 둘 것을 권장합니다. ^^




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





[최초 등록일: ]
[최종 수정일: 11/28/2019 ]

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

비밀번호

댓글 쓴 사람
 



2019-12-12 11시57분
[이광표] 부장님.. 덤프관련 내용 서치하다 글보고 댓글 남깁니다. 항시 도움 주셔서 감사합니다.
[손님]

1  2  3  4  5  6  7  8  [9]  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
12148정성태2/23/2020715디버깅 기술: 163. x64 환경에서 구현하는 다양한 Trampoline 기법
12147정성태2/27/2020569디버깅 기술: 162. x86/x64의 기계어 코드 최대 길이
12146정성태2/18/2020637.NET Framework: 893. eBEST C# XingAPI 래퍼 - 로그인 처리파일 다운로드1
12145정성태2/18/2020583.NET Framework: 892. eBEST C# XingAPI 래퍼 - Sqlite 지원 추가파일 다운로드1
12144정성태2/23/2020590.NET Framework: 891. 실행 시에 메서드 가로채기 - CLR Injection: Runtime Method Replacer 개선 - 두 번째 이야기파일 다운로드1
12143정성태2/13/2020442.NET Framework: 890. 상황별 GetFunctionPointer 반환값 정리 - x64파일 다운로드1
12142정성태2/27/2020601.NET Framework: 889. C# 코드로 접근하는 MethodDesc, MethodTable파일 다운로드1
12141정성태2/10/2020686.NET Framework: 888. C# - ASP.NET Core 웹 응용 프로그램의 출력 가로채기 [1]파일 다운로드1
12140정성태2/10/2020543.NET Framework: 887. C# - ASP.NET 웹 응용 프로그램의 출력 가로채기파일 다운로드1
12139정성태2/9/2020784.NET Framework: 886. C# - Console 응용 프로그램에서 UI 스레드 구현 방법
12138정성태2/9/2020944.NET Framework: 885. C# - 닷넷 응용 프로그램에서 Sqlite 사용 [3]파일 다운로드1
12137정성태2/9/2020500오류 유형: 592. [AhnLab] 경고 - 디버거 실행을 탐지했습니다.
12136정성태9/24/2020444Windows: 168. Windows + S(또는 Q)로 뜨는 작업 표시줄의 검색 바가 동작하지 않는 경우
12135정성태7/9/2020571개발 환경 구성: 468. Nuget 패키지의 로컬 보관 폴더를 옮기는 방법 [1]
12134정성태2/5/20201409.NET Framework: 884. eBEST XingAPI의 C# 래퍼 버전 - XingAPINet Nuget 패키지 [2]파일 다운로드1
12133정성태2/7/2020632디버깅 기술: 161. Windbg 환경에서 확인해 본 .NET 메서드 JIT 컴파일 전과 후 - 두 번째 이야기
12132정성태2/20/2020888.NET Framework: 883. C#으로 구현하는 Win32 API 후킹(예: Sleep 호출 가로채기)파일 다운로드1
12131정성태1/27/2020997개발 환경 구성: 467. LocaleEmulator를 이용해 유니코드를 지원하지 않는(한글이 깨지는) 프로그램을 실행하는 방법
12130정성태1/26/2020547VS.NET IDE: 142. Visual Studio에서 windbg의 "Open Executable..."처럼 EXE를 직접 열어 디버깅을 시작하는 방법
12129정성태1/26/20201866.NET Framework: 882. C# - 키움 Open API+ 사용 시 Registry 등록 없이 KHOpenAPI.ocx 사용하는 방법 [1]
12128정성태1/26/2020642오류 유형: 591. The code execution cannot proceed because mfc100.dll was not found. Reinstalling the program may fix this problem.
12127정성태1/28/2020665.NET Framework: 881. C# DLL에서 제공하는 Win32 export 함수의 내부 동작 방식(VT Fix up Table)파일 다운로드1
12126정성태1/25/2020611.NET Framework: 880. C# - PE 파일로부터 IMAGE_COR20_HEADER 및 VTableFixups 테이블 분석파일 다운로드1
12125정성태1/24/2020482VS.NET IDE: 141. IDE0019 - Use pattern matching
12124정성태1/24/20201050VS.NET IDE: 140. IDE1006 - Naming rule violation: These words must begin with upper case characters: ...
12123정성태1/23/2020833웹: 39. Google Analytics - gtag 함수를 이용해 페이지 URL 수정 및 별도의 이벤트 생성 방법
1  2  3  4  5  6  7  8  [9]  10  11  12  13  14  15  ...