最近线上的后台出现很诡异的部分线程池挂起,特别是在没有切时间的情况下出现quartz调度线程池卡死,因此获取现场信息就特别重要。
不料碰上更加诡异的情况,即kill -3 无法获取javacore(命令正常执行后,运行目录下没有javacore,且通过find -name *core无法找到)
(吐槽下某些IDC人。只会用IBM的webphere自带的admin来生成。。)
考虑到jvm用的是ibm的j9.只有祭出其杀招
1、通过内核自带的静态方法生成(coredump也可以生成,不过一般不需要这么大杀器,kill -6就够了)
@override
public void getJavaCore(){
com.ibm.jvm.Dump.
JavaDump
();
}
@override
public void get
heapDump(){
com.ibm.jvm.Dump.
HeapDump
();
}
2、通过jmx来调用,例行重启后加载验证,可以正常生成
3、由于网络设备抓报有大小限制,无法抓到完整的包,且从出问题的包来看,丢包率远小于20%,且由于rtt在200~500ms之间,
在每秒超过60*1kbytes报文的单条连接推送量下,可以发现即便用了netty异步发送,从发送窗口看,tcp的发送缓冲已经一直处于
90%的状态,发送队列堵塞严重
但是为什么出现应用线程池卡死还未有结论(即便出现bit反转,导致报文全部异常,netty或者应用线程池飘飞的概率也不高)
4、可以通过tcpdump 进行本机抓包验证
但是做好以上准备后,问题至今仍未重现,开发环境仍就也无法重现。。。
最近线上的后台出现很诡异的部分线程池挂起,特别是在没有切时间的情况下出现quartz调度线程池卡死,因此获取现场信息就特别重要。
不料碰上更加诡异的情况,即kill -3 无法获取javacore(命令正常执行后,运行目录下没有javacore,且通过find -name *core无法找到)
(吐槽下某些IDC人。只会用IBM的webphere自带的admin来生成。。)
考虑到jvm用的是ibm的j9.只有祭出其杀招
1、通过内核自带的静态方法生成(coredump也可以生成,不过一般不需要这么大杀器,kill -6就够了)
@override
public void getJavaCore(){
com.ibm.jvm.Dump.
JavaDump
();
}
@override
public void get
heapDump(){
com.ibm.jvm.Dump.
HeapDump
();
}
2、通过jmx来调用,例行重启后加载验证,可以正常生成
3、由于网络设备抓报有大小限制,无法抓到完整的包,且从出问题的包来看,丢包率远小于20%,且由于rtt在200~500ms之间,
在每秒超过60*1kbytes报文的单条连接推送量下,可以发现即便用了netty异步发送,从发送窗口看,tcp的发送缓冲已经一直处于
90%的状态,发送队列堵塞严重
但是为什么出现应用线程池卡死还未有结论(即便出现bit反转,导致报文全部异常,netty或者应用线程池飘飞的概率也不高)
4、可以通过tcpdump 进行本机抓包验证
但是做好以上准备后,问题至今仍未重现,开发环境仍就也无法重现。