덤프 파일을 사용하여 메모리 누수를 진단하려면 어떻게합니까?

덤프 파일을 사용하여 메모리 누수를 진단하려면 어떻게합니까?

---

약 80MB의 일반 개인 작업 세트가있는 .NET 서비스가 있습니다. 최근 부하 테스트 중에 프로세스가 3.5GB 메모리 사용량에 도달하여 전체 시스템의 실제 메모리가 부족 해졌고 (4GB 중 3.9GB 사용) 부하 테스트가 중지 된 지 오래지 않아 메모리가 해제되지 않았습니다. 작업 관리자를 사용하여 프로세스의 덤프 파일을 가져 와서 Visual Studio 2010 SP1에서 열어 디버깅을 시작할 수 있습니다.

메모리 문제를 어떻게 진단합니까? 마음에 드는 dotTrace Memory 3.x가 있는데 덤프 파일에 대한 메모리 프로파일 링을 지원합니까? 그렇지 않은 경우 Visual Studio 2010 Premium의 메모리 프로파일 링 기능이 도움이됩니까 (현재 Professional이 있음)? WinDbg가 도움이 될 수 있습니까?

업데이트 : 새로운 Visual Studio 2013 Ultimate 는 이제 덤프 파일을 사용하여 기본적으로 메모리 문제를 진단 할 수 있습니다. 자세한 내용은 이 블로그 게시물 을 참조하십시오.

---

WinDbg를 설치합니다. 덤프에 따라 올바른 버전 x86 또는 x64를 얻었는지 확인해야합니다. 다음은 x86 용 다운로드에 대한 직접 링크 입니다.

그것에 대해 올바른 덤프를 가져 왔는지 확인해야합니다. 작업 관리자를 사용하여 덤프 파일을 만들 수 있습니다 (프로세스-> 덤프 파일 만들기를 마우스 오른쪽 버튼으로 클릭). 64 비트이고 프로세스가 x86 인 경우 32 비트 버전의 작업 관리자 (C : \ Windows \ SysWOW64 \ taskmgr.exe)를 사용하여 덤프 파일을 가져옵니다. 예를 들어 XP를 사용 중이고 덤프 파일을 생성하기 위해 windbg를 사용해야하는 경우와 같이 덤프 파일을 가져 오는 방법에 대한 자세한 내용은 내 기사 를 참조하십시오 .

경고는 상당히 가파른 학습 곡선 거기에 사물이 여기에 설명 된대로 해당하므로, 어떠한 문제 돌아올 정확히 작동하지 않을 수 있습니다.

Visual Studio에서 덤프를 열 수 있다면 .NET4를 사용하고 있다고 가정합니다. 다음 은 dmp 파일 작업에 도움이 되는 매우 빠른 가이드입니다.

1) WinDbg를 실행하고 기호 경로 (파일-> 기호 검색 경로)를

SRV*c:\symbols*http://msdl.microsoft.com/download/symbols

2) 크래시 덤프를 열거 나 .DMP 파일을 WinDbg로 드래그하십시오.

3) 명령 창에 입력

.loadby sos clr

(참고로 .NET 2의 경우 명령은 .loadby sos mscorwks)

4) 다음을 입력하십시오

!dumpheap -stat

개체 유형과 개수를 나열합니다. 다음과 같이 보입니다.

응용 프로그램의 맥락에서 이것을 분석하고 특이한 것이 있는지 확인해야합니다.

windbg 에는 훨씬 더 많은 것이 있습니다. Google은 당신의 친구입니다.

---

일반적으로 관리되는 응용 프로그램에 누수가 있으면 무언가가 수집되지 않고 있음을 의미합니다. 일반적인 출처는 다음과 같습니다.

• 이벤트 처리기 : 구독자가 제거되지 않은 경우 게시자는 구독자를 유지합니다.

• 정적

• 종료 자 : 차단 된 종료자는 종료 자 스레드가 다른 종료자를 실행하지 못하도록하여 이러한 인스턴스가 수집되는 것을 방지합니다.

• 마찬가지로, 교착 상태 스레드는 자신이 보유한 루트를 유지합니다. 물론 여러 수준에서 응용 프로그램에 영향을 미칠 교착 상태 스레드가있는 경우입니다.

이 문제를 해결하려면 관리되는 힙을 검사해야합니다. WinDbg + SOS (또는 PSSCOR)를 사용하면이 작업을 수행 할 수 있습니다. 이 !dumpheap -stat명령은 전체 관리되는 힙을 나열합니다.

힙에서 예상되는 각 유형의 인스턴스 수를 알고 있어야합니다. 이상하게 보이는 것을 찾으면 !dumpheap -mt <METHOD TABLE>명령을 사용하여 주어진 유형의 모든 인스턴스를 나열 할 수 있습니다 .

다음 단계는 이러한 인스턴스의 루트를 분석하는 것입니다. 무작위로 하나를 선택하고 그것에 대해 수행하십시오 !gcroot. 특정 인스턴스가 어떻게 뿌리를 내 렸는지 보여줍니다. 이벤트 처리기와 고정 된 개체를 찾습니다 (일반적으로 정적 참조를 나타냄). 파이널 라이저 큐가 보이면 파이널 라이저 스레드가 무엇을하는지 조사해야합니다. 이를 위해 !threads및 !clrstack명령을 사용하십시오 .

해당 인스턴스에 대해 모든 것이 정상이면 다른 인스턴스로 이동합니다. 그래도 결과가 나오지 않으면 힙을 다시 살펴보고 거기에서 반복해야 할 수도 있습니다.

기타 누수 원인은 다음과 같습니다. 언로드되지 않은 어셈블리 및 대형 개체 힙의 조각화. SOS / PSSCOR도 이러한 위치를 찾는 데 도움이 될 수 있지만 지금은 세부 정보를 건너 뛰겠습니다.

더 알고 싶다면 Tess의 블로그를 추천 합니다. 또한 WinDbg + SOS ( 여기 와 여기 ) 를 사용하는 방법을 다루는 몇 가지 비디오를 만들었습니다 .

프로세스가 실행되는 동안 디버깅 할 수있는 옵션이 있다면 SOS 대신 PSSCOR 를 사용하는 것이 좋습니다 . PSSCOR는 기본적으로 추가 명령으로 개선 된 SOS 소스의 비공개 분기이며 기존 SOS 명령의 대부분도 개선되었습니다. 예를 들어 PSSCOR 버전의 !dumpheap명령에는 매우 유용한 델타 열이있어 메모리 누수 문제를 훨씬 쉽게 해결할 수 있습니다.

이를 사용하려면 프로세스를 시작하고 WinDbg를 연결하고 PSSCOR를로드 한 다음 !dumpheap -stat. 그런 다음 프로세스를 다시 실행하여 할당이 이루어 지도록합니다. 실행을 중단하고 명령을 반복하십시오. 이제 PSSCOR는 이전 검사 이후 추가 / 제거 된 인스턴스 수를 표시합니다.

---

버전 2017.2 이후 JetBrains dotMemory는 모든 강력하고 멋진 GUI로 Windows 메모리 덤프 분석을 지원합니다.

---

http://msdn.microsoft.com/en-us/library/ee817660.aspx

Microsoft에는 여기에 가이드가 있습니다. 그러나 초보자에게는 너무 힘들다.

dotTrace는 시각적 메모리 차트 (WinDbg보다 더 좋음)를 생성 할 수 있지만 덤프에는 사용하지 않습니다.

참고 URL : https://stackoverflow.com/questions/9514401/how-do-i-use-a-dump-file-to-diagnose-a-memory-leak