分析内存转储只显示DotMemory中的<未解决>引用

Question

分析内存转储只显示DotMemory中的<未解决>引用

dockermemory-leaksamazon-ecsdumpdotmemory

3

我在使用ECS部署的AWS Docker化微服务上遇到了内存泄漏问题。我想使用DotMemory分析转储，因此我使用exec连接到容器，使用gcore保存转储，然后将该转储传输到S3桶中以便下载。问题是，当我打开该转储时，一切都是“未解决的”，我无法理解发生了什么。

我尝试在本地运行相同的微服务并使用Windows任务管理器进行内存转储，一切正常。不幸的是，由于这是一个复杂的系统，我无法精确复制部署时的情况，因此我需要从我的部署的微服务创建可读取的转储。如何解决这个问题？

- MrDemien

你好 @MrDemien！我有一个类似的问题（除了转储是使用dotnet-monitor作为sidecar进行的）。我更新了coredump_filter标志为0x3f，并进行了新的转储，但没有运气，DotMemory中仍然是“未解决”的。你找到解决办法了吗？ - Bluezen

很遗憾，还没有。你试过使用“0x8f”吗？ - MrDemien

1

"0x3f" 已经将前6位设置为1。coredump_filter 最多考虑8位，因此我们可以尝试使用 "0xff" 将每个位都设置为1，但在我的情况下，这不应该改变任何内容。您可以在以下文档中查看每个位的含义：https://man7.org/linux/man-pages/man5/core.5.html - Bluezen

1

我已经创建了一种方法来重现问题，而JetBrains已经创建了一个工单。 - Bluezen

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Lenar · Answer 1

如果转储中缺少带有元数据的段，则可能出现此问题。

自内核2.6.23以来，Linux特定的/proc/[pid]/coredump_filter文件可用于控制在对应进程执行核心转储时写入哪些内存段到核心转储文件中。

请参阅core man章节“控制写入核心转储的映射”以获取更多信息。

为了获得dotNet进程的正确转储，coredump_filter应至少设置为0x3f。

您可以通过执行以下命令来检查进程的当前过滤器设置：

cat /proc/<pid>/coredump_filter

为设置适当的coredump_filter类型：

echo "0x3f" > /proc/<pid>/coredump_filter

<pid> 应该被替换为您的进程 ID，例如：

echo "0x3f" > /proc/144/coredump_filter

更新：2023年5月10日

我使用createdump实用程序成功地收集了包含所有必要信息的完整转储：

createdump -u -f /tmp/coredump <pid>

-u选项告诉createdump生成完整的内存转储，包括所有内存映射文件。请注意，对于使用大量内存或具有许多内存映射文件的应用程序，这将导致非常大的转储文件。

示例：

docker container exec -it \
  -u root --privileged \
  <container-id> \
  /usr/share/dotnet/shared/Microsoft.NETCore.App/6.0.16/createdump -u -f /tmp/coredump <pid>

docker cp <container-id>:/tmp/coredump .