代码之家  ›  专栏  ›  技术社区  ›  Kieren Johnstone

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

  •  2
  • Kieren Johnstone  · 技术社区  · 8 年前

    我有一个.NET核心应用程序,在Windows上使用高达~150MB,而在Linux上使用~1-2GB(不是虚拟机大小,而是实际的私有字节)。它在循环中调用azurehttpapi来检索统计信息。

    我想在Linux上诊断这个问题,但是我不知道工具。

    gdump ,并一直在跟踪 https://codeblog.dotsandbrackets.com/net-core-memory-linux/ . 在下面的例子中,它只是在一个演出下使用。

    我可以这么说:

    (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要少得多。很奇怪。)

    编辑:不运行 -最小值 谢天谢地,它以最大的内存用户结束。所以这就结束了:

    ...
    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

    1 回复  |  直到 8 年前
        1
  •  0
  •   Kieren Johnstone    8 年前

    对于.NET Core 2.1(netcoreapp2.1),内存使用率已经大大降低,并进入了一个可接受的范围。