1
서비스를 다시 시작하거나 프로세스가 종료되어 메모리를 해제 할 때까지 메모리 양을 많이 소비하는 상태 저장 서비스가 있습니다.서비스 패브릭 많은 양의 비 관리 메모리를 소비하는 상태 저장 서비스
아래 다이어그램을 참조하십시오. 어딘가에서 누설되는 전형적인 톱니 형태의 문제처럼 보입니다.
.
난 더 WinDbg는 전문가는 아니지만 그러나 나는 대부분의 메모리가 힙 스택에 의해 소비되고 있다는 제안 듯이 글을 따라 그것은 내가 스택을 얻기 위해 몇 가지 추가 명령을 사용한다고 제안(http://hacksoflife.blogspot.co.uk/2009/06/heap-debugging-memoryresource-leak-with.html)
추적하지만 dmp 파일 (gflags.exe/i yourApplication.exe + ust)을 사용하기 전에이 작업을 수행하지 않았습니다.내가 갖고있는 dmp 파일을 사용하여 문제를 진단하는 데 도움을 줄 수있는 사람이 있습니까?
누군가는이 문제를 찾으려고 다음 문서에 언급 된 단계는 가치가있을 것이라는 점을 확인할 수 있을까요? #
사람이 전에 상태 보존 형 서비스에 문제가 이런 종류의 경험 했습니까?
추가 정보 : 여기
이 DotMemory에서 검사 보고서의 이미지, 객체 누출 검사에 나는 우리의 코드에서 해당 개체를 인스턴스화 우리를 기억하지 않는 코드를 다시 확인해야합니다.
: 여기 내가!heap -s
0:000> !heap -s
************************************************************************************************************************
NT HEAP STATS BELOW
************************************************************************************************************************
LFH Key : 0x8b79585e7994c063
Termination on corruption : ENABLED
Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast
(k) (k) (k) (k) length blocks cont. heap
-------------------------------------------------------------------------------------
00000275bf510000 00000002 28701700 28609240 28701500 189846 42173 1804 5 2456d24 LFH
Lock contention 38104356
00000275bf3b0000 00008000 64 4 64 2 1 1 0 0
00000275bf780000 00001002 1280 368 1080 100 8 2 0 0 LFH
00000275bf710000 00001002 1280 388 1080 109 7 2 0 0 LFH
00000275bfc80000 00001002 1280 264 1080 7 9 2 0 0 LFH
00000275bfe70000 00041002 60 8 60 5 1 1 0 0
00000275d8730000 00041002 260 68 60 14 2 1 0 0 LFH
00000275d89a0000 00001002 31792 15028 31592 3404 244 14 3 106 LFH
External fragmentation 22 % (244 free blocks)
00000275d8950000 00001002 80356 19512 80156 17801 91 36 0 22 LFH
External fragmentation 91 % (91 free blocks)
00000275d8930000 00001002 1280 104 1080 29 4 2 0 0 LFH
00000275b2610000 00001002 1280 532 1080 62 15 2 0 1 LFH
00000275b0be0000 00001002 1280 88 1080 15 4 2 0 1 LFH
00000275b2840000 00001002 1280 556 1080 48 16 2 0 1 LFH
00000275b2bc0000 00001002 1280 92 1080 18 5 2 0 0 LFH
UPDATE 2017년 7월 12일에서 얻을 출력 내가 여기
0:000> !address -summary
Mapping file section regions...
Mapping module regions...
Mapping PEB regions...
Mapping TEB and stack regions...
Mapping heap regions...
Mapping page heap regions...
Mapping other regions...
Mapping stack trace database regions...
Mapping activation context regions...
--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
Free 865 7ff7`4c03d000 (127.966 TB) 99.97%
Heap 85669 6`e0f8e000 ( 27.515 GB) 79.04% 0.02%
<unknown> 21045 1`962b3000 ( 6.346 GB) 18.23% 0.00%
Stack 559 0`2f8c0000 (760.750 MB) 2.13% 0.00%
Image 1156 0`0d170000 (209.438 MB) 0.59% 0.00%
Other 9 0`001c7000 ( 1.777 MB) 0.00% 0.00%
TEB 189 0`0017a000 ( 1.477 MB) 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 106665 8`a403b000 ( 34.563 GB) 99.28% 0.03%
MEM_IMAGE 1906 0`0ecd1000 (236.816 MB) 0.66% 0.00%
MEM_MAPPED 57 0`012a7000 ( 18.652 MB) 0.05% 0.00%
--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_FREE 865 7ff7`4c03d000 (127.966 TB) 99.97%
MEM_COMMIT 96056 7`718c6000 ( 29.774 GB) 85.53% 0.02%
MEM_RESERVE 12572 1`426ed000 ( 5.038 GB) 14.47% 0.00%
--- Protect Summary (for commit) - RgnCount ----------- Total Size -------- %ofBusy %ofTotal
PAGE_READWRITE 53162 7`56794000 ( 29.351 GB) 84.31% 0.02%
PAGE_NOACCESS 41097 0`0a089000 (160.535 MB) 0.45% 0.00%
PAGE_EXECUTE_READ 120 0`08948000 (137.281 MB) 0.39% 0.00%
PAGE_READONLY 760 0`05996000 ( 89.586 MB) 0.25% 0.00%
PAGE_EXECUTE_READWRITE 423 0`01a3f000 ( 26.246 MB) 0.07% 0.00%
PAGE_WRITECOPY 259 0`00f4c000 ( 15.297 MB) 0.04% 0.00%
PAGE_READWRITE|PAGE_GUARD 185 0`0033b000 ( 3.230 MB) 0.01% 0.00%
PAGE_EXECUTE_WRITECOPY 50 0`00105000 ( 1.020 MB) 0.00% 0.00%
--- Largest Region by Usage ----------- Base Address -------- Region Size ----------
Free 27e`d5230000 7d77`29c10000 (125.465 TB)
Heap 276`50c95000 0`00d3a000 ( 13.227 MB)
<unknown> 275`81a2d000 0`1e5d3000 (485.824 MB)
Stack 14c`1f200000 0`00800000 ( 8.000 MB)
Image 7ffc`5d014000 0`01083000 ( 16.512 MB)
Other 275`bf920000 0`00181000 ( 1.504 MB)
TEB f9`09a04000 0`00002000 ( 8.000 kB)
PEB f9`09bf0000 0`00001000 ( 4.000 kB)
!address -summary을 실행 가지고 출력된다
의 출력 사용
우리는 항목의 다음과 같은 유형으로 0000 년대와 힙을 발견했습니다: 우리는에 FabricClient 인스턴스를 생성하는 우리의 BaseActor 클래스를 살펴 이것은 우리를 주도하고있다
0000027d680d8d60 0023 0023 [00] 0000027d680d8d70 00228 - (busy) ? FabricClient!GetFabricClientDefaultSettings+4ba320
구성을 Lazy<T>을 사용하여 처리하지만 절대로 처리하지 않으므로 현재 Actor 수명 내에서 FabricClient 인스턴스의 올바른 처리를 조사하고 있습니다.
상태 관리자에 추가하는 모든 항목에 메모리 할당이 커지나요? 이것이 실제 문제입니까? – LoekD
IMHO 단계가 정상입니다. 네이티브 코드를 제어 할 수 있습니까? 해당 코드의 구현을 변경하거나 사용 방법을 변경할 수 있습니까? 또한 .NET 코드의 버그 일 수도 있습니다. 어쩌면 당신은 뭔가 처분해야합니다. 당신은 이미 dotMemory를 가지고있을 것이므로 (잠재적으로 어떻게 사용 하는지를 알고 있기 때문에) .NET 객체 누수를 먼저 찾은 다음 그 누수가 기본 누출과 관련 될 수 있는지 확인하십시오. –
안녕하세요 @LoekD - 좋은 질문을 제기합니다. 전에 이와 비슷한 것을 가지고 있었고 SF 팀과 이야기를 나누었고 사전에 추가 된 고정 된 (그리고 많은) 빈 항목이있는 것처럼 보였습니다. 그래서 내 질문이 될 수도, 어떻게하면 더 많은 리소스를 요구하는 다음에서 배우 서비스를 중지 서버가 있습니까? 액터의 수명은 모두 기본값입니다. –