问题描述
我能够根据此处的描述生成 Jeprofile 输出,如下所示
需要帮助来了解问题出在哪里?
环境是:Centos 7Java 1.8.0海湾合作委员会 9
谢谢!
在您的 jemalloc 输出中,
JVM_FindSignal
占分配的 97%.这不可能是真的,因为JVM_FindSignal
没有分配任何东西.这一定是JVM没有调试符号.按照此答案中的说明安装带有 JDK 调试符号的包,或使用带有内置调试符号的 JDK,例如利比里亚 JDK.
jemalloc
对 Java 方法一无所知.它无法将 JIT 编译代码中的地址转换为 Java 方法名称.因此,您的 jemalloc 输出中有这么多地址(十六进制数字).有一个 Java 分析器,async-profiler,可以跟踪本机内存分配到 Java 代码,并将 Java 堆栈跟踪显示为火焰图.使用 async-profiler 分析
malloc
、mprotect
和mmap
调用有助于查找本机内存泄漏.有关详细信息,请参阅此答案.有一个 演示视频,展示了使用 jemalloc 和 async 分析本机分配的示例-分析器.
I was able to generate the Jeprofile output as follows based on the descriptions present here jemalloc post
Please find the jemalloc output and the graph.
> Using local file /bin/java. Using local file jeprof.57473.0.f.heap.
> Total: 79372091 B 78084060 98.4% 98.4% 78084060 98.4%
> je_prof_backtrace 1288031 1.6% 100.0% 1474342 1.9%
> Java_java_util_zip_ZipFile_getZipMessage
> 0 0.0% 100.0% 6889972 8.7% 0x00007f3d5ebac3e6
> 0 0.0% 100.0% 270421 0.3% 0x00007f3d5ebb8a79
> 0 0.0% 100.0% 727762 0.9% 0x00007f3d5ebb8a87
> 0 0.0% 100.0% 589239 0.7% 0x00007f3d5ebb9ab2
> 0 0.0% 100.0% 854269 1.1% 0x00007f3d5ebb9ac0
> 0 0.0% 100.0% 270421 0.3% 0x00007f3d5ebb9cb7
> 0 0.0% 100.0% 135210 0.2% 0x00007f3d5ebbc5fa
> 0 0.0% 100.0% 135210 0.2% 0x00007f3d5ebbc768
> 0 0.0% 100.0% 135210 0.2% 0x00007f3d5ee57146
> 0 0.0% 100.0% 143743 0.2% 0x00007f3d5ee8bc25
> 0 0.0% 100.0% 444413 0.6% 0x00007f3d5ef13945
> 0 0.0% 100.0% 136258 0.2% 0x00007f3d5ef764fb
> 0 0.0% 100.0% 8463202 10.7% 0x00007f3d5efbdb8a
> 0 0.0% 100.0% 143743 0.2% 0x00007f3d5f220c67
> 0 0.0% 100.0% 135210 0.2% 0x00007f3d5f3a5c65
> 0 0.0% 100.0% 55473738 69.9% AsyncGetCallTrace
> 0 0.0% 100.0% 48103708 60.6% JLI_GetStdArgc
> 0 0.0% 100.0% 48103708 60.6% JNI_CreateJavaVM
> 0 0.0% 100.0% 11897251 15.0% JNI_GetCreatedJavaVMs
> 0 0.0% 100.0% 11897251 15.0% JVM_DefineClassWithSource
> 0 0.0% 100.0% 271469 0.3% JVM_FindClassFromBootLoader
> 0 0.0% 100.0% 431486 0.5% JVM_FindClassFromCaller
> 0 0.0% 100.0% 131120 0.2% JVM_FindLoadedClass
> 0 0.0% 100.0% 76994237 97.0% JVM_FindSignal
> 0 0.0% 100.0% 148137 0.2% JVM_GetCPMethodClassNameUTF
> 0 0.0% 100.0% 148137 0.2% JVM_GetCPMethodSignatureUTF
> 0 0.0% 100.0% 135210 0.2% JVM_GetClassDeclaredFields
> 0 0.0% 100.0% 405631 0.5% JVM_GetClassName
> 0 0.0% 100.0% 143743 0.2% JVM_IHashCode
> 0 0.0% 100.0% 143743 0.2% JVM_MonitorWait
> 0 0.0% 100.0% 431486 0.5% JVM_RawMonitorExit
> 0 0.0% 100.0% 659324 0.8% JVM_StartThread
> 0 0.0% 100.0% 77220036 97.3% JVM_handle_linux_signal
> 0 0.0% 100.0% 11897251 15.0% Java_java_lang_ClassLoader_defineClass1
> 0 0.0% 100.0% 271469 0.3% Java_java_lang_ClassLoader_findBootstrapClass
> 0 0.0% 100.0% 431486 0.5% Java_java_lang_Class_forName0
> 0 0.0% 100.0% 592551 0.7% Java_java_util_zip_Inflater_inflateBytes
> 0 0.0% 100.0% 134688 0.2% Java_java_util_zip_Inflater_init
> 0 0.0% 100.0% 1117359 1.4% Java_java_util_zip_ZipFile_open
> 0 0.0% 100.0% 75438262 95.0% SUNWprivate_1.1
> 0 0.0% 100.0% 296275 0.4% VerifyClassForMajorVersion
> 0 0.0% 100.0% 356982 0.4% ZIP_Open
> 0 0.0% 100.0% 1474342 1.9% ZIP_Unlock
> 0 0.0% 100.0% 176271 0.2% _GLOBAL__sub_I_eh_alloc.cc
> 0 0.0% 100.0% 176271 0.2% _GLOBAL__sub_I_eh_alloc.cc (inline)
> 0 0.0% 100.0% 59721527 75.2% __clone
> 0 0.0% 100.0% 176271 0.2% __static_initialization_and_destruction_0 (inline)
> 0 0.0% 100.0% 176271 0.2% _dl_init_internal
> 0 0.0% 100.0% 176271 0.2% _dl_start_user
> 0 0.0% 100.0% 131184 0.2% fork1
> 0 0.0% 100.0% 78084060 98.4% imalloc (inline)
> 0 0.0% 100.0% 78084060 98.4% imalloc_body (inline)
> 0 0.0% 100.0% 592551 0.7% inflate
> 0 0.0% 100.0% 592551 0.7% inflateBackEnd
> 0 0.0% 100.0% 134688 0.2% inflateInit2_
> 0 0.0% 100.0% 78084060 98.4% je_malloc_default
> 0 0.0% 100.0% 78084060 98.4% prof_alloc_prep (inline)
> 0 0.0% 100.0% 59721527 75.2% start_thread
The graph is also attached
Need some help in understanding where the problem is?
Enviornment is:Centos 7Java 1.8.0GCC 9
Thank!
In your jemalloc output,
JVM_FindSignal
is accounted for 97% of allocations. This can't be true, sinceJVM_FindSignal
does not allocate anything.This must be the result of the issue that JVM has no debug symbols. Install the package with JDK debug symbols as descibed in this answer, or use JDK with built-in debug symbols, e.g. Liberica JDK.
jemalloc
does not know anything about Java methods. It can't translate the addresses in JIT compiled code to Java method names. Hence so many addresses (hex numbers) in your jemalloc output.There is a Java profiler, async-profiler, that can trace native memory allocations down to Java code, and show Java stack traces as Flame Graphs. Profiling
malloc
,mprotect
andmmap
calls with async-profiler can be helpful in finding native memory leaks. See this answer for details.There is a presentation video showing an example of profiling native allocations with both jemalloc and async-profiler.
这篇关于了解 Jeprofile 输出的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!