Microsoft MVP성태의 닷넷 이야기
Linux: 26. .NET Core 응용 프로그램을 위한 메모리 덤프 방법 [링크 복사], [링크+제목 복사]
조회: 13074
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 2개 있습니다.)
(시리즈 글이 6개 있습니다.)
Linux: 26. .NET Core 응용 프로그램을 위한 메모리 덤프 방법
; https://www.sysnet.pe.kr/2/0/12078

Linux: 27. linux - lldb를 이용한 .NET Core 응용 프로그램의 메모리 덤프 분석 방법
; https://www.sysnet.pe.kr/2/0/12083

.NET Framework: 2053. 리눅스 환경의 .NET Core 3/5+ 메모리 덤프를 분석하는 방법 - 두 번째 이야기
; https://www.sysnet.pe.kr/2/0/13135

.NET Framework: 2054. .NET Core/5+ SDK 설치 없이 dotnet-dump 사용하는 방법
; https://www.sysnet.pe.kr/2/0/13136

.NET Framework: 2055. 리눅스 환경의 .NET Core 3/5+ 메모리 덤프로부터 닷넷 모듈을 추출하는 방법
; https://www.sysnet.pe.kr/2/0/13137

.NET Framework: 2057. 리눅스 환경의 .NET Core 3/5+ 메모리 덤프로부터 모든 닷넷 모듈을 추출하는 방법
; https://www.sysnet.pe.kr/2/0/13139




linux - .NET Core 응용 프로그램을 위한 메모리 덤프 방법

리눅스 용 ProcDump가 나온 것은 아실 테고, ^^

microsoft/ProcDump-for-Linux
; https://github.com/Microsoft/ProcDump-for-Linux

Minimum OS:
    Red Hat Enterprise Linux / CentOS 7
    Fedora 26
    Ubuntu 14.04 LTS
gdb >= 7.6.1
zlib (build-time only)


설치 방법은 아래의 링크에서 자세하게 설명하지만,

Ubuntu 18.04 Package Manager - Install .NET Core
; https://learn.microsoft.com/en-us/dotnet/core/install/linux-package-manager-ubuntu-1804

(Ubuntu 18.04의 경우) 어차피 Microsoft Key와 Feed 등록은,

$ wget -q https://packages.microsoft.com/config/ubuntu/18.04/packages-microsoft-prod.deb -O packages-microsoft-prod.deb
$ sudo dpkg -i packages-microsoft-prod.deb

.NET Core SDK를 이미 설치한 경우 함께 등록했을 것이므로 그냥 곧바로 procdump를 설치해도 됩니다.

[설치] 
$ sudo apt-get install procdump

[제거]
$ sudo apt-get purge procdump

아쉬운 점이 있다면, procdump의 제어 옵션이 많지 않아서 (대부분의 경우) 그냥 process id 정도만 지정해 실행 중인 응용 프로그램을 덤프하는 용도로 사용할 수 있다는 점입니다.

$ sudo procdump -p 18362

그 외에 특정 예외가 발생했을 때라든지, 비정상 종료할 때와 같은 옵션이 없으므로 현실적으로 봤을 때 아직 사용처가 그다지 많지는 않습니다.




procdump 말고, .NET 런타임이 제공하는 createdump도 있습니다. 사실 현재는 procdump가 아직 크게 장점이 없으므로 그냥 기본 제공하는 createdump를 쓰는 것이 더 나을 수 있습니다.

$ readlink $(which dotnet) -f
/usr/share/dotnet/dotnet

$ $(find /usr/share/dotnet -name createdump)
createdump [options] pid
-f, --name - dump path and file name. The pid can be placed in the name with %d. The default is '/tmp/coredump.%d'
-n, --normal - create minidump.
-h, --withheap - create minidump with heap (default).
-t, --triage - create triage minidump.
-u, --full - create full core dump.
-d, --diag - enable diagnostic messages.

또는 (SCD 방식으로) publish된 .NET Core 응용 프로그램의 경우 배포된 바이너리에도 createdump를 포함하고 있으므로 그것을 사용해도 됩니다. (기본적으로 실행 권한이 없어 사용하기 전 chmod로 권한 변경을 해야 합니다.)

$ chmod u+x /home/tusr/corecorelin/createdump
$ /home/tusr/corecorelin/createdump

닷넷 응용 프로그램을 분석하려면 (Windows에서도 그랬듯이) full memory dump를 받아야 하므로 createdump에 "-u" 옵션을 주는 것을 잊지 말아야 합니다.

$ sudo $(find /usr/share/dotnet -name createdump) -u 55130




어차피 createdump나 procdump는 리눅스의 gcore 방식을 사용한다고 합니다. 그래서 다음의 글에도 나오지만, gcore로 뜬 덤프로도 분석이 가능합니다.

Analyzing .NET Core memory on Linux with LLDB
; https://codeblog.dotsandbrackets.com/net-core-memory-linux/

(따지고 보면 한 가지이지만) 이 3가지 방식의 문제는, 덤프 파일의 크기입니다. Full 메모리 덤프이기 때문에 해당 프로세스와 연관된 모든 메모리를 덤프하는데 pmap이 알려주는 메모리 크기라고 보시면 됩니다.

$ ps -Af | grep dotnet
root       9873      1  1 13:42 ?        00:00:56 /usr/share/dotnet/dotnet /home/tusr/corecorelin/CoreCoreLin.dll
root      17227 102608  0 15:01 pts/2    00:00:00 grep --color=auto dotnet

$ sudo pmap 9873 | grep total
...[생략]...
 total         22161860K

CoreCoreLin.dll은 비주얼 스튜디오가 생성해 주는 ASP.NET Core 기본 예제를 빌드한 것인데 (비록 압축을 하면 70MB 정도로 줄어들기는 하지만) 거의 22GB에 달하는 덤프 파일이 생성됩니다. (Centos 7에서 테스트하면 7GB 정도의 덤프가 생성됩니다.) ^^; 이 때문에 일부 리눅스 설정에서는,

#ulimit -a

ulimit의 "core file size" 제약이 있는 경우 덤프를 뜨기 전 "unlimited"로 풀어줄 필요가 있습니다.

#ulimit -c unlimited

참고로 procdump의 경우에는 향후 크기가 줄어들 여지가 있는데요,

How to reduce the dump file size ?
; https://github.com/Microsoft/ProcDump-for-Linux/issues/33

현재 새롭게 만들고 있는 core dumper가 구현된다면 그때에나 procdump가 createdump에 비해 쓸만할 수 있을 것입니다.




마지막으로 .NET Core 3 이상의 환경이라면 dotnet-dump 도구를 활용하는 방법도 있습니다.

덤프 수집 및 분석 유틸리티(dotnet-dump)
; https://learn.microsoft.com/ko-kr/dotnet/core/diagnostics/dotnet-dump

설치는 별도로 해야 하지만,

# dotnet tool install -g dotnet-dump

# /home/$USER/.dotnet/tools/dotnet-dump --help
Usage:
  dotnet-dump [options] [command]

Options:
  --version    Display version information

Commands:
  collect                Capture dumps from a process
  analyze     Starts an interactive shell with debugging commands to explore a dump
  ps                     Display a list of dotnet processes to create dump from

편리하게도 "ps" 옵션을 주면 실행 중인 프로세스 중에 ".NET Core 3.0" 이상의 런타임을 사용하는 목록만 나열하기 때문에,

$ sudo dotnet-dump ps
     25604 dotnet     /usr/share/dotnet/dotnet

그에 대해 "collect" 명령어로 덤프를 뜨면 됩니다.

$ sudo dotnet-dump collect --process-id 25604

// 만약 .NET Core 3.0 미만의 런타임을 사용하는 프로세스를 지정하면 오류 발생
$ sudo dotnet-dump collect -p 6154
Writing minidump with heap to /home/tusr/temp/core_20191213_101617
Process 6154 not running compatible .NET Core runtime

그런데, 웬일인지 제가 테스트했을 때는,

$ sudo dotnet-dump collect -p 25604
Writing minidump with heap to /home/tusr/temp/core_20191213_094748
Core dump generation FAILED 0x80004005

저렇게 0x80004005 오류가 발생하는 데, Ubuntu 18.04와 Centos 7 모두에서 덤프가 안 됩니다. 실행이 안 되므로 더 이상 실습을 할 수가 없군요. ^^; 일단 문서 상으로 보면,

The dotnet-dump CLI global tool is way to collect and analyze Windows and Linux dumps all without any native debugger involved like lldb on Linux. This is important on platforms like Alpine Linux or Linux ARM32/ARM64 where a fully working lldb isn't available. The dotnet-dump tool will allow you to run SOS commands to analyze crashes and the GC, but it isn't a native debugger so things like displaying the native stack frames isn't supported.

Currently not supported on macOS.


용량이 꽤나 줄어드는 것은 맞겠지만 그에 따라 "native stack frames" 등의 정보가 지원되지 않는다는 걸로 봐서는 웬만한 환경에서는 그냥 createdump로 뜨는 것이 더 나을 수 있습니다. 디버깅 해보신 분들은 알겠지만, 때로는 GC Heap 이외의 정보도 필요하기 때문에 기왕 덤프 뜨는 거 모든 정보를 갖는 파일 하나가... 제 생각에는 더 좋겠다는 생각입니다.




정리해 보면, 현재 시점 기준으로는 createdump가 가장 나은 듯합니다. 다른 덤프 방법들은 상황에 따라 잘 활용하시면 될 것 같고. ^^




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 7/20/2023]

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

비밀번호

댓글 작성자
 



2020-02-13 10시12분
정성태
2021-01-14 01시50분
정성태
2021-05-24 02시51분
정성태

... 16  17  [18]  19  20  21  22  23  24  25  26  27  28  29  30  ...
NoWriterDateCnt.TitleFile(s)
13178정성태12/1/20224836Windows: 215. Win32 API 금지된 함수 - IsBadXxxPtr 유의 함수들이 안전하지 않은 이유파일 다운로드1
13177정성태11/30/20225569오류 유형: 829. uwsgi 설치 시 fatal error: Python.h: No such file or directory
13176정성태11/29/20224489오류 유형: 828. gunicorn - ModuleNotFoundError: No module named 'flask'
13175정성태11/29/20226110오류 유형: 827. Python - ImportError: cannot import name 'html5lib' from 'pip._vendor'
13174정성태11/28/20224682.NET Framework: 2073. C# - VMMap처럼 스택 메모리의 reserve/guard/commit 상태 출력파일 다운로드1
13173정성태11/27/20225367.NET Framework: 2072. 닷넷 응용 프로그램의 스레드 스택 크기 변경
13172정성태11/25/20225178.NET Framework: 2071. 닷넷에서 ESP/RSP 레지스터 값을 구하는 방법파일 다운로드1
13171정성태11/25/20224788Windows: 214. 윈도우 - 스레드 스택의 "red zone"
13170정성태11/24/20225098Windows: 213. 윈도우 - 싱글 스레드는 컨텍스트 스위칭이 없을까요?
13169정성태11/23/20225683Windows: 212. 윈도우의 Protected Process (Light) 보안 [1]파일 다운로드2
13168정성태11/22/20224975제니퍼 .NET: 31. 제니퍼 닷넷 적용 사례 (9) - DB 서비스에 부하가 걸렸다?!
13167정성태11/21/20225013.NET Framework: 2070. .NET 7 - Console.ReadKey와 리눅스의 터미널 타입
13166정성태11/20/20224741개발 환경 구성: 651. Windows 사용자 경험으로 WSL 환경에 dotnet 런타임/SDK 설치 방법
13165정성태11/18/20224643개발 환경 구성: 650. Azure - "scm" 프로세스와 엮인 서비스 모음
13164정성태11/18/20225541개발 환경 구성: 649. Azure - 비주얼 스튜디오를 이용한 AppService 원격 디버그 방법
13163정성태11/17/20225479개발 환경 구성: 648. 비주얼 스튜디오에서 안드로이드 기기 인식하는 방법
13162정성태11/15/20226552.NET Framework: 2069. .NET 7 - AOT(ahead-of-time) 컴파일
13161정성태11/14/20225776.NET Framework: 2068. C# - PublishSingleFile로 배포한 이미지의 역어셈블 가능 여부 (난독화 필요성) [4]
13160정성태11/11/20225721.NET Framework: 2067. C# - PublishSingleFile 적용 시 native/managed 모듈 통합 옵션
13159정성태11/10/20228922.NET Framework: 2066. C# - PublishSingleFile과 관련된 옵션 [3]
13158정성태11/9/20225206오류 유형: 826. Workload definition 'wasm-tools' in manifest 'microsoft.net.workload.mono.toolchain' [...] conflicts with manifest 'microsoft.net.workload.mono.toolchain.net7'
13157정성태11/8/20225862.NET Framework: 2065. C# - Mutex의 비동기 버전파일 다운로드1
13156정성태11/7/20226772.NET Framework: 2064. C# - Mutex와 Semaphore/SemaphoreSlim 차이점파일 다운로드1
13155정성태11/4/20226268디버깅 기술: 183. TCP 동시 접속 (연결이 아닌) 시도를 1개로 제한한 서버
13154정성태11/3/20225748.NET Framework: 2063. .NET 5+부터 지원되는 GC.GetGCMemoryInfo파일 다운로드1
13153정성태11/2/20227025.NET Framework: 2062. C# - 코드로 재현하는 소켓 상태(SYN_SENT, SYN_RECV)
... 16  17  [18]  19  20  21  22  23  24  25  26  27  28  29  30  ...