asyncprofiler malloc 未定义类别
asyncprofiler malloc undefined category
我已经设置并使用了 https://github.com/jvm-profiling-tools/async-profiler,这非常有用,但我有一件奇怪的事情无法解释。
我的设置正是多个演示文稿显示它可以提供帮助的地方:
带有节点池的 AKS kubernetes 集群
一个节点上部署的pod
在容器中我设置了带有 debuginfo
的 openjdk-11
分析设置很简单 ./profiler start -e malloc PID
因为我在虚拟化环境中分析工作,我得到的唯一警告是
[WARN] Kernel symbols are unavailable due to restrictions. Try
sysctl kernel.kptr_restrict=0
sysctl kernel.perf_event_paranoid=1
我认为关于 malloc 调用捕获可能不需要。
问题是,经过一段时间的分析后,我捕获了火焰图显示的分配部分:堆栈跟踪“未知”(见附图)。可能是我仍然没有在容器中进行完整设置,或者我真的需要这些 sysctl?
问题是将它们放置到位的虚拟化并不是微不足道的,因为据我所知,这实际上影响了我们 运行 上的底层节点。
Flame graphs for allocations
更新
现在,在我的微服务的所有主要功能至少触发一次后,我重新启动了分析,似乎没有未知的分配。愚蠢的问题,但是我会不会在所有类加载发生之前立即开始分析(因为 bean 是惰性实例化的),这就是为什么它被这样分类的原因?
更新 2
实际上我的假设是错误的我做了一个很好的转储
不久之后又发生了同样的现象,据报道大量捕获的 malloc 事件是未知的,top 没有显着增加。这可能是由于虚拟化,我实际上是从同一节点上的其他容器捕获事件吗?在我的容器中没有更多的 java 进程,我也直接指定 PID
更新 3
因此,在 Andrei 向我提供“矮人栈行者”之后,这看起来好多了。我只有一个问题还不清楚,但只有我一个人。我们在这里分析 malloc 事件与我的:
./profile.sh 启动 --cstack dwarf -e malloc PID
所以我在这些火焰图上看到的是:它只是可以同时释放的捕获事件编号,还是它当前由所有这些 mallocs 持有本机内存?
我目前的情况是,我看到 payara-micro healthcheck 和 autodeploy 拥有大量内存,这很奇怪,这是我对泄漏源的第一个猜测。
我还制作了一个 jeprof 输出,有人猜猜“updatewindow/inflate”可以指向什么吗?
这里不涉及容器环境
您系统上的 libc
(其中 malloc
实现所在)似乎是在没有帧指针的情况下编译的。因此内核中的标准堆栈遍历机制无法找到 malloc
帧的父级。
我最近实现了另一种依赖于 DWARF unwinding information. New version has not been yet released, but you may try to build it from sources. Or, for your convenience, I prepared the new build here: async-profiler-2.6-dwarf-linux-x64.tar.gz
的堆栈遍历算法
然后添加 --cstack dwarf
选项,所有 malloc
堆栈跟踪应该就位。
我已经设置并使用了 https://github.com/jvm-profiling-tools/async-profiler,这非常有用,但我有一件奇怪的事情无法解释。
我的设置正是多个演示文稿显示它可以提供帮助的地方:
带有节点池的 AKS kubernetes 集群
一个节点上部署的pod
在容器中我设置了带有 debuginfo
的 openjdk-11分析设置很简单 ./profiler start -e malloc PID
因为我在虚拟化环境中分析工作,我得到的唯一警告是
[WARN] Kernel symbols are unavailable due to restrictions. Try sysctl kernel.kptr_restrict=0 sysctl kernel.perf_event_paranoid=1
我认为关于 malloc 调用捕获可能不需要。
问题是,经过一段时间的分析后,我捕获了火焰图显示的分配部分:堆栈跟踪“未知”(见附图)。可能是我仍然没有在容器中进行完整设置,或者我真的需要这些 sysctl?
问题是将它们放置到位的虚拟化并不是微不足道的,因为据我所知,这实际上影响了我们 运行 上的底层节点。
Flame graphs for allocations
更新
现在,在我的微服务的所有主要功能至少触发一次后,我重新启动了分析,似乎没有未知的分配。愚蠢的问题,但是我会不会在所有类加载发生之前立即开始分析(因为 bean 是惰性实例化的),这就是为什么它被这样分类的原因?
更新 2
实际上我的假设是错误的我做了一个很好的转储
不久之后又发生了同样的现象,据报道大量捕获的 malloc 事件是未知的,top 没有显着增加。这可能是由于虚拟化,我实际上是从同一节点上的其他容器捕获事件吗?在我的容器中没有更多的 java 进程,我也直接指定 PID
更新 3
因此,在 Andrei 向我提供“矮人栈行者”之后,这看起来好多了。我只有一个问题还不清楚,但只有我一个人。我们在这里分析 malloc 事件与我的: ./profile.sh 启动 --cstack dwarf -e malloc PID 所以我在这些火焰图上看到的是:它只是可以同时释放的捕获事件编号,还是它当前由所有这些 mallocs 持有本机内存?
我目前的情况是,我看到 payara-micro healthcheck 和 autodeploy 拥有大量内存,这很奇怪,这是我对泄漏源的第一个猜测。
我还制作了一个 jeprof 输出,有人猜猜“updatewindow/inflate”可以指向什么吗?
这里不涉及容器环境
您系统上的 libc
(其中 malloc
实现所在)似乎是在没有帧指针的情况下编译的。因此内核中的标准堆栈遍历机制无法找到 malloc
帧的父级。
我最近实现了另一种依赖于 DWARF unwinding information. New version has not been yet released, but you may try to build it from sources. Or, for your convenience, I prepared the new build here: async-profiler-2.6-dwarf-linux-x64.tar.gz
的堆栈遍历算法然后添加 --cstack dwarf
选项,所有 malloc
堆栈跟踪应该就位。