Linux 上的 .NET Core - LLDB、SOS 插件 - 诊断内存问题答案

【问题标题】：.NET Core on Linux - LLDB, SOS plugin - diagnosing memory issueLinux 上的 .NET Core - LLDB、SOS 插件 - 诊断内存问题
【发布时间】：2019-01-29 16:28:19
【问题描述】：

我有一个 .NET Core 应用程序，它在 Windows 上最多使用 ~150MB，但在 Linux 上使用 ~1-2GB（不是 VM 大小，而是实际的私有字节）。它循环调用 Azure HTTP API 来检索统计信息。

我想在 Linux 上诊断问题，但我不知道工具。

我通过gdump 进行了转储，并且一直在关注https://codeblog.dotsandbrackets.com/net-core-memory-linux/。在下面的例子中，它正在使用一个 gig。

我可以做到这一点：

(lldb) sos DumpHeap -stat -min 10000
Statistics:
              MT    Count    TotalSize Class Name
00007f88ebedf438        2       131120 Microsoft.EntityFrameworkCore.ChangeTracking.Internal.InternalEntityEntry[]
00007f88ebed5438        1       202080 System.Collections.Generic.Dictionary`2+Entry[[System.String, System.Private.CoreLib],[Microsoft.EntityFrameworkCore.ChangeTracking.Internal.InternalEntityEntry, Microsoft.EntityFrameworkCore]][]
00007f88ebec6328        1       202080 System.Collections.Generic.Dictionary`2+Entry[[System.Object, System.Private.CoreLib],[Microsoft.EntityFrameworkCore.ChangeTracking.Internal.InternalEntityEntry, Microsoft.EntityFrameworkCore]][]
00007f88e8c92660        4       432604 System.Byte[]
00007f88e8cdf228        4       865120 System.String
0000000001e2d2c0       36      6008920      Free

（如果没有 -min 选项，我会得到太多输出来读取/执行任何操作）

大约 600MB 的免费空间是可疑的，但我不知道这意味着什么、如何补救，或者接下来要尝试的任何其他 SOS 命令。 SOS 文档 (https://github.com/dotnet/coreclr/blob/master/src/ToolBox/SOS/Strike/sosdocs.txt) 看起来很棒，但我的理解水平还不够高，无法在这里汇总诊断过程。

（一些上下文：我在 Kubernetes 上运行，有一个 RAM 请求和限制设置为 ~2GB，但这个过程一直在达到它。正如我所说，在 Windows 上它使用更少的 RAM。很奇怪。）

编辑：在没有-min 的情况下运行确实以看起来最大的内存用户结束。到此结束：

...
00007f88ebec5de0     4727       340344 Microsoft.EntityFrameworkCore.ChangeTracking.Internal.InternalClrEntityEntry
00007f88e8c91d00     6484       347528 System.Int32[]
00007f88e9e9e0b8     9434       377360 UNKNOWN
00007f88ea4222d8     4836       386880 Microsoft.Azure.Management.Monitor.Fluent.Models.MetricDefinition
00007f88ebe47f28     9672       464256 Microsoft.Azure.Management.Monitor.Fluent.Models.MetricAvailability
00007f88e9e9f110     9433       528248 UNKNOWN
00007f88e9e9e2f8     9434       528304 UNKNOWN
00007f88ebe42a78     4836       580320 Microsoft.Azure.Management.Monitor.Fluent.Models.MetricDefinitionImpl
00007f88ea423158     3837      1074360 azure2elasticstack.Program+<ProcessMetricAsync>d__10
00007f88e8c92660     1832      2315924 System.Byte[]
00007f88e8cdf228    44713     10688048 System.String
0000000001e2d2c0    22762     22762768      Free
Total 289009 objects
(lldb)

在这里回购：https://github.com/kierenj/proto-azure2elasticstack/tree/master

【问题讨论】：

OOM？被杀？ Kubernetes？这听起来像这个错误：github.com/dotnet/coreclr/pull/19518
太棒了，这看起来像一个非常相似的问题 omajid。但是，top 仍然显示此应用在 Linux 下使用 ~7 倍的 RAM

标签： .net linux debugging .net-core lldb

【解决方案1】：

.NET Core 2.1 (netcoreapp2.1) 的内存使用率下降到了可观的范围内。

【讨论】：