Service Fabric Stateful Service消耗大量非托管内存

Question

我有一个有状态服务，它会消耗越来越多的内存，直到服务重新启动或进程被终止，然后释放内存。

见下图;它看起来像典型的锯齿型内存泄漏问题。

我们使用DotMemory对集群中单个节点的内存使用情况进行了一些分析，并报告了所占用的绝大部分内存都在非托管内存中。

在我们循环有状态服务之前，我们采用了一个内存转储文件，看看我们是否可以使用WinDbg进一步学习。

我没有WinDbg专家，但我遵循了这篇文章，这似乎表明大部分内存都被堆栈使用（http://hacksoflife.blogspot.co.uk/2009/06/heap-debugging-memoryresource-leak-with.html）

它建议我应该使用一些额外的命令来获取堆栈跟踪，但在获取dmp文件（gflags.exe / i yourApplication.exe + ust）之前我没有这样做。

是否有人可以使用我拥有的dmp文件帮助我诊断问题？

有人可以验证文章中提到的步骤是否值得尝试查找此问题？＃

以前有没有人遇到有状态服务的这类问题？

附加信息：

以下是DotMemory检查报告的图像，关于对象泄漏检查，我需要重新检查代码，我不记得我们在代码中实例化这些对象。

以下是我从运行!address -summary

获得的输出

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)

以下是我从!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

更新07/12/2017：

使用!heap -flt s 228

的输出

我们找到了一个包含0000以及以下类型条目的堆：

0000027d680d8d60 0023 0023 [00] 0000027d680d8d70 00228 - (busy) ? FabricClient!GetFabricClientDefaultSettings+4ba320

这导致我们看看我们的BaseActor类，我们使用Lazy<T>在结构中创建一个FabricClient实例，但从不处理它，因此我目前正在调查正确的处理方法。 Actor生命周期内的FabricClient实例。

Answer 1

在Microsoft支持部门的帮助下，我们发现FabricClient存在问题。

显然，处理FabricClient存在已知问题，并且将在SDK 6.2中修复。

目前我们已经迁移了我们的代码，使用静态变量来保存每个服务的FabricClient单个实例。

Answer 2

由于我们的主题是追踪非托管内存泄漏，JetBrain的dotTrace工具是一个强大且易于使用的 真正 工具。请阅读https://blog.jetbrains.com/dotnet/2017/01/23/analyzing-native-memory-allocation-with-dottrace-2016-3/。虽然本文描述了该工具的早期版本，但我也可以使用最新版本的信息。