上下文:我正在研究一个意外泄漏管道的基于Java的网络服务器。它每隔几天就达到40,000个文件描述符的限制并死掉。在死亡之前在服务器上使用lsof
显示它被管道堵塞。管道连接到自身,而不是另一个过程。
我们可以看到代码库的任何部分都没有创建或使用管道。
JVM的一些旧版本创建了&在创建套接字时泄漏了一个管道,但是这在java 1.7.0_75上展示了,我相信它不会遭受这个bug。
我的问题是:使用现代Linux工具链(例如perf)可以在调用pipe(2)
系统调用时对进程进行快照 - 我相信这是唯一的方式管道被创建。此外,是否有可能从那个?
鉴于此信息,应该可以回答“谁在创建管道,为什么?”这个问题。
答案 0 :(得分:3)
在java 1.7.0_75(或pre-java 8 update 60)上,您只能从事件调用堆栈上的perf获取有限信息,因为堆栈将被截断(见下文)。
您可以在sys调用管道上获取系统范围的跟踪点事件,并使用以下perf命令或类似命令关闭。
perf record -e 'syscalls:sys_enter_pipe*' -e 'syscalls:sys_enter_close' -ag -- sleep 10
获得完整堆栈:
截断的堆栈将是底部没有线程启动功能的堆栈,例如:
java 19575 [018] 10600910.346655: syscalls:sys_enter_pipe: fildes: 0x7f353b9f7f80
7f3809cff0b7 __pipe (/usr/lib64/libc-2.17.so)
7f37f59aecb9 [unknown] (/tmp/perf-19375.map)
7f37f5e83150 [unknown] (/tmp/perf-19375.map)
edb4639ef8034082 [unknown] ([unknown])
完整堆栈可能看起来更像:
java 21553 [009] 10601254.522385: syscalls:sys_enter_pipe: fildes: 0x7f545322f340
7f54527180b7 __pipe (/usr/lib64/libc-2.17.so)
7f543d007760 [unknown] (/tmp/perf-21552.map)
7f543d0007a7 [unknown] (/tmp/perf-21552.map)
7f5451ce1be6 JavaCalls::call_helper (/usr/java/jdk1.8.0_60/jre/lib/amd64/server/libjvm.so)
7f5451fe7b27 Reflection::invoke (/usr/java/jdk1.8.0_60/jre/lib/amd64/server/libjvm.so)
7f5451feb237 Reflection::invoke_method (/usr/java/jdk1.8.0_60/jre/lib/amd64/server/libjvm.so)
7f5451d705fb JVM_InvokeMethod (/usr/java/jdk1.8.0_60/jre/lib/amd64/server/libjvm.so)
7f543da669ed [unknown] (/tmp/perf-21552.map)
7f543d0007a7 [unknown] (/tmp/perf-21552.map)
7f5451ce1be6 JavaCalls::call_helper (/usr/java/jdk1.8.0_60/jre/lib/amd64/server/libjvm.so)
7f5451d23182 jni_invoke_static (/usr/java/jdk1.8.0_60/jre/lib/amd64/server/libjvm.so)
7f5451d3fb8a jni_CallStaticVoidMethod (/usr/java/jdk1.8.0_60/jre/lib/amd64/server/libjvm.so)
7f5452bfcbcc JavaMain (/usr/java/jdk1.8.0_60/jre/lib/amd64/jli/libjli.so)
7f5452e12df5 start_thread (/usr/lib64/libpthread-2.17.so)
使用perf-map-agent运行以允许perf将JITted [unknown]函数解析为java方法。
关于如何做到这一点还有其他各种指南,包括Brendan Gregg的工作http://techblog.netflix.com/2015/07/java-in-flames.html