Đây là ứng dụng dịch vụ .NET v4 windows đang chạy trên máy x64. Tại một số thời điểm sau những ngày chạy liên tục, mức tiêu thụ bộ nhớ dịch vụ Windows tăng đột biến như điên cho đến khi nó bị treo. Tôi đã có thể bắt nó ở 1,2 GB và chụp một bãi chứa bộ nhớ. Đây là những gì tôi nhận đượcCách phân tích <unclassified> sử dụng bộ nhớ trong windbg
Nếu tôi chạy! Giải quyết -summary trong windbg trên tập tin dump của tôi tôi nhận được kết quả sau
! Giải quyết -summary
--- Usage Summary ------ RgnCount ------- Total Size -------- %ofBusy %ofTotal
Free 821 7ff`7e834000 ( 7.998 Tb) 99.98%
<unclassified> 3696 0`6eece000 ( 1.733 Gb) 85.67% 0.02%
Image 1851 0`0ea6f000 (234.434 Mb) 11.32% 0.00%
Stack 1881 0`03968000 ( 57.406 Mb) 2.77% 0.00%
TEB 628 0`004e8000 ( 4.906 Mb) 0.24% 0.00%
NlsTables 1 0`00023000 (140.000 kb) 0.01% 0.00%
ActivationContextData 3 0`00006000 ( 24.000 kb) 0.00% 0.00%
CsrSharedMemory 1 0`00005000 ( 20.000 kb) 0.00% 0.00%
PEB 1 0`00001000 ( 4.000 kb) 0.00% 0.00%
-
-
-
--- Type Summary (for busy) -- RgnCount ----- Total Size ----- %ofBusy %ofTotal
MEM_PRIVATE 5837 0`7115a000 ( 1.767 Gb) 87.34% 0.02%
MEM_IMAGE 2185 0`0f131000 (241.191 Mb) 11.64% 0.00%
MEM_MAPPED 40 0`01531000 (21.191 Mb) 1.02% 0.00%
-
-
--- State Summary ------------ RgnCount ------ Total Size ---- %ofBusy %ofTotal
MEM_FREE 821 7ff`7e834000 ( 7.998 Tb) 99.98%
MEM_COMMIT 6127 0`4fd5e000 ( 1.247 Gb) 61.66% 0.02%
MEM_RESERVE 1935 0`31a5e000 (794.367 Mb) 38.34% 0.01%
-
-
--Protect Summary(for commit)- RgnCount ------ Total Size --- %ofBusy %ofTotal
PAGE_READWRITE 3412 0`3e862000 (1000.383 Mb) 48.29% 0.01%
PAGE_EXECUTE_READ 220 0`0b12f000 (177.184 Mb) 8.55% 0.00%
PAGE_READONLY 646 0`02fd0000 ( 47.813 Mb) 2.31% 0.00%
PAGE_WRITECOPY 410 0`01781000 ( 23.504 Mb) 1.13% 0.00%
PAGE_READWRITE|PAGE_GUARD 1224 0`012f2000 ( 18.945 Mb) 0.91% 0.00%
PAGE_EXECUTE_READWRITE 144 0`007b9000 ( 7.723 Mb) 0.37% 0.00%
PAGE_EXECUTE_WRITECOPY 70 0`001cd000 ( 1.801 Mb) 0.09% 0.00%
PAGE_EXECUTE 1 0`00004000 ( 16.000 kb) 0.00% 0.00%
-
-
--- Largest Region by Usage ----Base Address -------- Region Size ----------
Free 0`8fff0000 7fe`59050000 ( 7.994 Tb)
<unclassified> 0`80d92000 0`0f25e000 (242.367 Mb)
Image fe`f6255000 0`0125a000 ( 18.352 Mb)
Stack 0`014d0000 0`000fc000 (1008.000 kb)
TEB 0`7ffde000 0`00002000 ( 8.000 kb)
NlsTables 7ff`fffb0000 0`00023000 (140.000 kb)
ActivationContextData 0`00030000 0`00004000 ( 16.000 kb)
CsrSharedMemory 0`7efe0000 0`00005000 ( 20.000 kb)
PEB 7ff`fffdd000 0`00001000 ( 4.000 kb)
Thứ nhất, tại sao không được phân loại chương trình lên một lần 1,73 GB và thời gian khác là 242 MB. (Điều này đã được trả lời. Cảm ơn bạn)
Thứ hai, tôi hiểu rằng chưa được phân loại có thể có nghĩa là mã được quản lý, tuy nhiên kích thước heap của tôi theo! Eeheap chỉ 248 MB, thực sự khớp với 242 nhưng thậm chí không gần 1,73GB. Kích thước tệp kết xuất là 1,2 GB cao hơn nhiều so với bình thường. Tôi phải đi đâu từ đây để tìm hiểu xem cái gì đang sử dụng hết bộ nhớ. Bất cứ điều gì trong thế giới quản lý heap là dưới 248 MB, nhưng tôi đang sử dụng 1,2 GB.
Cảm ơn
EDIT
Nếu tôi làm! Đống -Si nhận được như sau
LFH Key : 0x000000171fab7f20
Termination on corruption : ENABLED
Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast
(k) (k) (k) (k) length blocks cont. heap
-------------------------------------------------------------------------------------
Virtual block: 00000000017e0000 - 00000000017e0000 (size 0000000000000000)
Virtual block: 0000000045bd0000 - 0000000045bd0000 (size 0000000000000000)
Virtual block: 000000006fff0000 - 000000006fff0000 (size 0000000000000000)
0000000000060000 00000002 113024 102028 113024 27343 1542 11 3 1c LFH
External fragmentation 26 % (1542 free blocks)
0000000000010000 00008000 64 4 64 1 1 1 0 0
0000000000480000 00001002 3136 1380 3136 20 8 3 0 0 LFH
0000000000640000 00041002 512 8 512 3 1 1 0 0
0000000000800000 00001002 3136 1412 3136 15 7 3 0 0 LFH
00000000009d0000 00001002 3136 1380 3136 19 7 3 0 0 LFH
00000000008a0000 00041002 512 16 512 3 1 1 0 0
0000000000630000 00001002 7232 3628 7232 18 53 4 0 0 LFH
0000000000da0000 00041002 1536 856 1536 1 1 2 0 0 LFH
0000000000ef0000 00041002 1536 944 1536 4 12 2 0 0 LFH
00000000034b0000 00001002 1536 1452 1536 6 17 2 0 0 LFH
00000000019c0000 00001002 3136 1396 3136 16 6 3 0 0 LFH
0000000003be0000 00001002 1536 1072 1536 5 7 2 0 3 LFH
0000000003dc0000 00011002 512 220 512 100 60 1 0 2
0000000002520000 00001002 512 8 512 3 2 1 0 0
0000000003b60000 00001002 339712 168996 339712 151494 976 116 0 18 LFH
External fragmentation 89 % (976 free blocks)
Virtual address fragmentation 50 % (116 uncommited ranges)
0000000003f20000 00001002 64 8 64 3 1 1 0 0
0000000003d90000 00001002 64 8 64 3 1 1 0 0
0000000003ee0000 00001002 64 16 64 11 1 1 0 0
-------------------------------------------------------------------------------------
Sử dụng tệp dll SOS và nhìn vào đống theo cách đó. Vì đây là một chương trình .net phân bổ đống được thực hiện bởi khung .net không hiển thị trong vùng không được quản lý. – Zipper
kích thước heap của tôi theo! Eeheap (sos.dll) chỉ là 248 MB. Vì vậy, tôi không chắc chắn đó là nguyên nhân của kích thước quá trình 1,2 GB, cũng không phải nguyên nhân của 1,7 GB chưa phân loại, trừ khi tôi thiếu một cái gì đó – Mark
Dịch vụ của bạn làm gì? Dịch vụ của bạn có chứa mã không được quản lý hoặc mã C++/CLI không? Nó trông giống như một rò rỉ bộ nhớ không được quản lý. GDI, đối tượng người dùng, số lượng xử lý nói gì? Trong đó ngăn xếp cuộc gọi là chủ đề của bạn bị mắc kẹt? ~ * e! ClrStack và ~ * e! DumpStack và ~ * ekv là bạn của bạn để xem chủ đề của bạn đang làm gì. Là một sợi ở giữa phân bổ một cái gì đó? –