2009-10-13 24 views
6

Tôi đang cố gắng tìm hiểu lý do tại sao một số đối tượng trong ứng dụng của tôi được ghim. Các đối tượng tôi đã xem xét cho đến nay là mảng đối tượng! Gcroot đang hiển thị mảng như đang được ghim nhưng tôi không biết làm thế nào để tìm ra lý do tại sao nó được ghim.Cách xác định lý do tại sao đối tượng được ghim

Output:

0:000> !dumpobj 0239cea0 
Name: System.Object[] 
MethodTable: 793041d0 
EEClass: 790eda54 
Size: 528(0x210) bytes 
Array: Rank 1, Number of elements 128, Type CLASS 
Element Type: System.Object 
Fields: 
None 

0:000> !gcroot 0239cea0 
Note: Roots found on stacks may be false positives. Run "!help gcroot" for 
more info. 
Scan Thread 0 OSTHread f3c 
Scan Thread 2 OSTHread e54 
Scan Thread 4 OSTHread 748 
Scan Thread 5 OSTHread fe0 
Scan Thread 7 OSTHread 7a0 
Scan Thread 9 OSTHread cf4 
Scan Thread 10 OSTHread a6c 
Scan Thread 11 OSTHread bc4 
Scan Thread 12 OSTHread 598 
Scan Thread 13 OSTHread a8 
Scan Thread 14 OSTHread 50c 
Scan Thread 15 OSTHread ba4 
Scan Thread 16 OSTHread b40 
Scan Thread 17 OSTHread 534 
Scan Thread 18 OSTHread 5fc 
Scan Thread 19 OSTHread dfc 
Scan Thread 20 OSTHread cc4 
Scan Thread 21 OSTHread f84 
Scan Thread 22 OSTHread 9f4 
Scan Thread 23 OSTHread ff0 
Scan Thread 24 OSTHread fb0 
Scan Thread 25 OSTHread c14 
Scan Thread 29 OSTHread 5c4 
DOMAIN(0015EB90):HANDLE(Pinned):971e74:Root:0239cea0(System.Object[]) 
DOMAIN(0015EB90):HANDLE(WeakSh):971e74:Root:0239cea0(System.Object[]) 
DOMAIN(0015EB90):HANDLE(WeakSh):971e74:Root:0239cea0(System.Object[]) 
DOMAIN(0015EB90):HANDLE(WeakSh):971e74:Root:0239cea0(System.Object[]) 
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[]) 
DOMAIN(0015EB90):HANDLE(WeakSh):971e74:Root:0239cea0(System.Object[]) 
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[]) 
DOMAIN(0015EB90):HANDLE(WeakSh):971e74:Root:0239cea0(System.Object[]) 
DOMAIN(0015EB90):HANDLE(WeakSh):971e74:Root:0239cea0(System.Object[]) 
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[]) 
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[]) 
DOMAIN(0015EB90):HANDLE(WeakSh):971e74:Root:0239cea0(System.Object[]) 
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[]) 
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[]) 
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[]) 
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[]) 
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[]) 
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[]) 
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[]) 
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[]) 
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[]) 
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[]) 
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[]) 
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[]) 
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[]) 
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[]) 
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[]) 
DOMAIN(0015EB90):HANDLE(Unknwn):971e74:Root:0239cea0(System.Object[]) 

Chỉnh sửa: Added eeheap -gc đầu ra

!eeheap -gc 
Number of GC Heaps: 1 
generation 0 starts at 0x49a6f940 
generation 1 starts at 0x49a0c8a8 
generation 2 starts at 0x01301000 
ephemeral segment allocation context: none 
segment begin allocated  size 
01300000 01301000 022f05a0 0x00fef5a0(16709024) 
0d0d0000 0d0d1000 0e0bb0cc 0x00fea0cc(16687308) 
0e9e0000 0e9e1000 0f9de3e8 0x00ffd3e8(16765928) 
11020000 11021000 12014808 0x00ff3808(16726024) 
15020000 15021000 15ff3958 0x00fd2958(16591192) 
139f0000 139f1000 1499f584 0x00fae584(16442756) 
16020000 16021000 16fd7c30 0x00fb6c30(16477232) 
19020000 19021000 1a013df4 0x00ff2df4(16723444) 
17020000 17021000 17fcfe8c 0x00faee8c(16445068) 
18020000 18021000 18fedb84 0x00fccb84(16567172) 
1a020000 1a021000 1afc8814 0x00fa7814(16414740) 
26010000 26011000 26f97d2c 0x00f86d2c(16280876) 
2d010000 2d011000 2df97210 0x00f86210(16278032) 
20010000 20011000 210028e0 0x00ff18e0(16718048) 
21010000 21011000 220085d8 0x00ff75d8(16741848) 
23810000 23811000 247acf60 0x00f9bf60(16367456) 
28010000 28011000 28f84f80 0x00f73f80(16203648) 
1c010000 1c011000 1cfba544 0x00fa9544(16422212) 
1d010000 1d011000 1dfdcf64 0x00fcbf64(16564068) 
32010000 32011000 32f9189c 0x00f8089c(16255132) 
1e010000 1e011000 1eff9824 0x00fe8824(16680996) 
2c010000 2c011000 2cfd4904 0x00fc3904(16529668) 
300a0000 300a1000 3104a488 0x00fa9488(16422024) 
24810000 24811000 2571bd20 0x00f0ad20(15772960) 
36d10000 36d11000 37c982d4 0x00f872d4(16282324) 
29010000 29011000 29fc96a0 0x00fb86a0(16484000) 
27010000 27011000 27ee38bc 0x00ed28bc(15542460) 
2a010000 2a011000 2afab094 0x00f9a094(16359572) 
441c0000 441c1000 45149df0 0x00f88df0(16289264) 
38d10000 38d11000 39ce4254 0x00fd3254(16593492) 
3bd10000 3bd11000 3cc7a750 0x00f69750(16160592) 
3ad10000 3ad11000 3bc8b878 0x00f7a878(16230520) 
411c0000 411c1000 421655a0 0x00fa45a0(16401824) 
2b010000 2b011000 2bfafae4 0x00f9eae4(16378596) 
461c0000 461c1000 471a1bb0 0x00fe0bb0(16649136) 
3e1c0000 3e1c1000 3f11151c 0x00f5051c(16057628) 
34010000 34011000 35003ae4 0x00ff2ae4(16722660) 
451c0000 451c1000 4609e680 0x00edd680(15586944) 
4c1c0000 4c1c1000 4d105324 0x00f44324(16007972) 
2f0a0000 2f0a1000 3007989c 0x00fd889c(16615580) 
50e10000 50e11000 51cf17d8 0x00ee07d8(15599576) 
33010000 33011000 34005d88 0x00ff4d88(16731528) 
37d10000 37d11000 38cc6d7c 0x00fb5d7c(16473468) 
481c0000 481c1000 4898a468 0x007c9468(8164456) 
39d10000 39d11000 3acbe2d8 0x00fad2d8(16437976) 
3f1c0000 3f1c1000 3fd1f378 0x00b5e378(11920248) 
51e10000 51e11000 52e01018 0x00ff0018(16711704) 
431c0000 431c1000 441805d8 0x00fbf5d8(16512472) 
401c0000 401c1000 4116b2b0 0x00faa2b0(16425648) 
421c0000 421c1000 430da254 0x00f19254(15831636) 
491c0000 491c1000 49b98e0c 0x009d7e0c(10321420) 
Large object heap starts at 0x02301000 
segment begin allocated  size 
02300000 02301000 02f1bf20 0x00c1af20(12693280) 
Total Size 0x31786160(829972832) 
------------------------------ 
GC Heap Size 0x31786160(829972832) 

Trả lời

3

Lệnh !findroots trong .NET 4's SOS (hoặc !refs trong SOSEX) đợi cho đến khi GC tiếp theo (bạn có thể chỉ định thế hệ nào) và sau đó sẽ đến bạn sẽ có những gì rễ đối tượng có.

1

Theo kinh nghiệm của tôi nó là hiếm khi hữu ích để nhìn vào Object[] vì nó là loại cơ bản của rất nhiều loại , có nghĩa là bạn sẽ kết thúc với rất nhiều trong số này trên heap làm cho nó khó khăn hơn để xác định một trong những chính xác. Ngoài ra các cấu trúc bên trong như interned string table cũng được lưu trữ dưới dạng Object[].

Nếu bạn đang cố gắng tìm ra lý do tại sao ứng dụng sử dụng nhiều bộ nhớ, hãy thử xác định các loại khác có thể hoặc không thể đóng gói Object[] và tìm hiểu nguồn gốc của chúng.

Nếu bạn cung cấp thêm thông tin về những gì bạn đang cố gắng hoàn thành, tôi có thể cung cấp lời khuyên cụ thể hơn.

CHỈNH SỬA: Phân mảnh không nhất thiết phải xấu vì có thể âm thanh và 100 MB miễn phí không đánh tôi là một con số cao đáng báo động. Bạn đã xác định được liệu các khối miễn phí có nằm trong đống thế hệ lớn trên đống đối tượng lớn không?

Đầu ra của !eeheap -gc là gì?

+0

tôi đang xem xét phân mảnh bộ nhớ có thể cho các vấn đề oom Tôi gặp. Sử dụng http://www.zhaun.net/post/Debugging-NET-virtual-memory-fragmentation-with-WinDbg.aspx làm điểm bắt đầu. Tôi thấy rất khác nhau! Gcroot đầu ra trong bộ nhớ dump tôi có có 48093 đối tượng miễn phí tiêu thụ 112MB các tập tin dump là 1.2GB. Chạy một gcroot mất khoảng 30 phút vì vậy tôi chỉ có thể lấy mẫu các đối tượng ngẫu nhiên. Tôi không nghĩ loại đối tượng là quan trọng, chỉ là một thứ gì đó đã được ghim. Đây chỉ là một điều chúng tôi đang xem xét cho các vấn đề OOM. Đã có một sự kiện 300MB rò rỉ hơn 10 giờ –

+0

Trong kế hoạch lớn của sự vật 100MB không phải là lớn, nhưng nó có thể được lộn xộn lên mọi thứ. Tôi tin rằng đối tượng mà tôi đang xem xét trong gen2, nó là một ứng dụng máy tính để bàn vì vậy hầu hết mọi thứ kết thúc trong gen2. Các LOH như 60MB miễn phí –

+0

Sử dụng heap của bạn là 800 MB và eeheap cho thấy phần lớn là trên gen 2 đống trong khi chỉ có một chút là trên LOH. Nếu bạn muốn xác định các khối miễn phí, bạn có thể làm một! Dumpheap -type Free –

4

GCRoot thường sẽ không cho bạn biết lý do tại sao thứ gì đó được ghim. Rất nhiều mảng đối tượng mà bạn tìm thấy trong CLR được sử dụng cho nội bộ. Thay vào đó, đọc nhận xét của bạn về câu trả lời khác, tôi có thể đề nghị bạn nên bắt đầu với một thứ gì đó khác để theo dõi rò rỉ bộ nhớ của bạn không?

Bắt đầu với "! Dumpheap -stat" và xem những người dùng bộ nhớ lớn nhất ở đó. Tuy nhiên, bỏ qua các kiểu CLR cơ bản như đối tượng [], chuỗi,… Tìm đối tượng đối tượng của bạn (được định nghĩa là "không phải cái gì đó trong mscorlib hoặc system.dll) có ở đó và tìm ra nguồn gốc của nó. Đó là thường là dễ dàng hơn để theo dõi sự rò rỉ từ hướng đó, ngay cả khi nó chỉ ra rằng bạn đang rò rỉ một loại nguyên thủy trong ứng dụng của bạn.

+0

Có, đó là lý do tại sao tôi hỏi làm thế nào để xác định lý do tại sao một đối tượng được ghim. gcroot chỉ nói với tôi rằng một đối tượng được ghim. –

+0

Không có cách nào để xác định lý do tại sao một đối tượng được ghim theo như tôi biết. Một lần nữa, quay trở lại ví dụ cụ thể này, một ghim vào một mảng đối tượng là cách chúng ta lưu trữ các biến tĩnh trong CLR. Vì vậy, bạn có thể nhìn vào nơi chúng tôi nhà biến tĩnh, nhưng tôi không thể chắc chắn. Một số chốt được ghim, bạn có thể cho biết lý do tại sao chúng được ghim theo loại (xử lý RefCnt, ví dụ, chỉ được sử dụng trong com-interop). Nói chung, mặc dù bạn không thể xác định lý do tại sao một đối tượng đang được ghim mà không cần truy cập vào các nguồn và biểu tượng CLR. –

0
+0

Chỉ liên kết các câu trả lời không được khuyến khích trên Stack Overflow. Nếu liên kết bị hỏng, thông tin gần như vô dụng. Tốt hơn bao gồm các phần liên quan như một đoạn trích cho câu trả lời. Cảm ơn. –

Các vấn đề liên quan