본문 바로가기

.NET/Debugging

Windbg툴로 관리힙 메모리 디버깅하기 1

http://blogs.msdn.com/b/alejacma/archive/2009/08/13/managed-debugging-with-windbg-managed-heap-part-1.aspx

이 내용은 위의 기사를 토대로 만들어 졌습니다. 다소 상이한 부분이 있을수 있습니다. 이미지는 그대로 썼습니다.
 
.NET 는 NT Heap을 사용하지 않고 대신에 고유의 managed heap을 씁니다.

모든 Object들은 managed heap안에서 GC에 의해 0세대 1세대 2세대로 관리됩니다.

모든 object는 처음에 0세대로 시작을 합니다. 단 85,000bytes 이상인 object들은 Large Object Heap(LOH)에 관리됩니다. 

85,000bytes라는 사이즈는 실제적인 object사이즈 즉 자식 object(member 변수)들을 제외한 사이즈가 되겠습니다. 

LOH의 대부분의 아이템들은 string그리고 large array들입니다.

object가 할당 될때 GC는 각 세대의 한계치를 체크하게 됩니다. 그래서 한계치에 이르르면 GC가 구동됩니다.

세대의 한계치는 application의 보다 낳은 메모리 할당 프로세스를 위해 다이나믹하게 변경됩니다.(고정된 값이아님)

만약 GC가 일어나는 동안 object가 application의 root에 참조되고 있다면  그 object는 승격(promotion)되고 0=>1 , 1=>2 이렇게 세대가 증가하게 됩니다.

단 2세대에 있는 object들과 LOH에 있는 object들은 예외가 되겠습니다(왜인지 아시죠?)

 여기서 왜  LOH를 사용하는가 하면 2가지 이유가 있는데 첫번째로는 Large object가 할당되면 이것은 유저가 어느기간 동안 그 객체를 쓸거라는 가정이 이고, 두번쨰로는 large object는 다음 세대로 옮기기에 너무 비용이 비싸기 떄문입니다. 그래서 그러한 이유로 LOH의 영역안에 있는 object들은 GC가 다른 세대에 비해 Collection을 덜 수행합니다.
게대가 LOH의  객체들은 compaction(메모리 재요청)을 안합니다. LOH 를 사용할때는 주위해 주세요.

이번에는 finalize메서드가 있는 object에 관해 얘기해 보겠습니다.

application root에서 참조를 더이상 하고 있지 않는 object에 대해 GC가 일어났을때 그 object는 승격(promotion)이 됩니다.  단 dispose메소드를 호출했다면 승격되지 않고 사라집니다.
 
이제 부터는 windbg툴을 사용하는 법을 간단히 보겠습니다(sos.dll extension을 사용). ㅋㅋ (저도 아직 잘 몰라요)

 http://it-developer.tistory.com/trackback/91 이 주소에 설명한대로 windbg와 symbols를 다운받고 설치합니다.

 C:\Program Files\Debugging Tools for Windows (x86)안에 있는 windbg.exe를 실행합니다.

file => symbol file path =>
C:\Windows\symbols\dll 확인을 누릅니다.


file => Attach to process누르시고 디버깅하기 원하는 프로세스를 선택해 줍니다.

 
 


위의 표시된 부분 처름 .load C:\Windows\Microsoft.NET\Framework\v4.0.30319\sos.dll 을 로드합니다. 냠냠 이제 실행해보죠


0:004> !EEVersion

2.0.50727.1433 retail

Workstation mode

SOS Version: 2.0.50727.42 retail build

0:004> !EEHeap -gc

Number of GC Heaps: 1

generation 0 starts at 0x01901018

generation 1 starts at 0x0190100c

generation 2 starts at 0x01901000

ephemeral segment allocation context: none

segment begin allocated size

00423878 7b463c40 7b47a744 0x00016b04(92932)

0041d178 7a733370 7a754b98 0x00021828(137256)

003d6600 790d8620 790f7d8c 0x0001f76c(128876)

01900000 01901000 01949ff4 0x00048ff4(298996)

Large object heap starts at 0x02901000

segment begin allocated size

02900000 02901000 02907df0 0x00006df0(28144)

Total Size 0xa787c(686204)

------------------------------

GC Heap Size 0xa787c(686204)


 냠냠 잘 돼죠? 저도 해봤는데 잘 되네요

위의 데이터를 보니 GC Heap이 하나 있네요 그리고 Large object heap이 하나 있고요

 위에서 보면 GC의 모드가 workstation mode로 나왔있네요 만약 저거 Server mode이면 각 CPU core당 1나의 heap이 생성되게 됩니다. 참고 ㅋㅋ

냠냠 오늘은 여기까지 하죠 더 많은걸 보시면 처음에 링크주소를 이용하세요