linux - DotNet Core 2.1 在 Linux 中囤积内存

Question

我有一个 websocket 服务器，它会在几天内囤积内存，直到 Kubernetes 最终将其杀死。我们使用 prometheous-net 监控它.

# dotnet --info

Host (useful for support):
  Version: 2.1.6
  Commit:  3f4f8eebd8

.NET Core SDKs installed:
  No SDKs were found.

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.6 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.6 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.6 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

但是当我远程连接并进行内存转储(使用 createdump)时，内存突然下降......服务没有停止、重新启动或失去任何连接的用户。请参见图片中的绿线。

我可以在图表中看到，GC 在所有代中都有规律地收集。

GC 服务器被禁用使用:

<PropertyGroup>
  <ServerGarbageCollection>false</ServerGarbageCollection>
</PropertyGroup>

在禁用 GC 服务器之前，该服务用于更快地增加内存。现在需要两周时间才能达到 512Mb。

其他以请求/响应方式使用 ASP.NET Core 的服务不会出现此问题。这使用 Websockets，其中每个连接通常持续 10 分钟左右......所以我想与连接相关的所有内容都可以轻松地保留到第 2 代。

请注意，有两个 pod，表现出相同的行为，然后一个(绿色)由于进行内存转储而在内存使用中突然下降。

在获取内存转储期间 Pod 没有重启:

没有连接丢失或重新启动。

堆:

(lldb) eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x00007F8481C8D0B0
generation 1 starts at 0x00007F8481C7E820
generation 2 starts at 0x00007F852A1D7000
ephemeral segment allocation context: none
         segment             begin         allocated              size
00007F852A1D6000  00007F852A1D7000  00007F853A1D5E90  0xfffee90(268430992)
00007F84807D0000  00007F84807D1000  00007F8482278000  0x1aa7000(27947008)
Large object heap starts at 0x00007F853A1D7000
         segment             begin         allocated              size
00007F853A1D6000  00007F853A1D7000  00007F853A7C60F8  0x5ef0f8(6222072)
Total Size:              Size: 0x12094f88 (302600072) bytes.
------------------------------
GC Heap Size:            Size: 0x12094f88 (302600072) bytes.
(lldb)

免费对象:

(lldb) dumpheap -type Free -stat
Statistics:
              MT    Count    TotalSize Class Name
00000000010c52b0   219774     10740482      Free
Total 219774 objects

对这种行为有什么解释吗？

Answer 1

问题出在与 RabbitMQ 的连接上。因为我们使用的是对事件 channel 进行排序，所以 RabbitMQ.Client 的“自动重新连接”功能保留了很多关于死 channel 的状态。我们关闭了这个配置，因为我们不需要“自动重新连接”功能的“特权”，一切都开始正常工作。这很痛苦，但我们基本上必须设置 Windows 部署并使用 Windows 工具(在本例中为 Jetbrains dotMemory)执行通常的内存分析过程。使用 lldb 根本没有生产力。