关于 -XX:+ShowMessageBoxOnError 和 check:jni 参数
 |
xiaoyu
2012-04-05
对于某些生产上的JVM内存太大. 如果奔溃后做core dump, 可能时间非常长. 是否有必要使用 -XX:+ShowMessageBoxOnError 这个参数呢? 如果使用了这个参数, 会不会有副作用呢?
对于JVM Crash的情况, 是否有必要在生产上加 check:jni 参数, 输出更多JNI相关的信息? |
 |
RednaxelaFX
2012-04-05
Oracle JDK / OpenJDK里，-XX:+ShowMessageBoxOnError 这个参数的主要作用是当一个Java进程crash的时候，在打出crash log之前先弹出“提示框”让用户有机会连接一个调试器到这个Java进程上，做现场调试。“提示框”不一定真的是图形界面的“框”，在Linux上的实现默认是字符界面的。
如果在提示框点了“确定”或输入“y”表示确认，那么接下来会自动启动调试器连接上了；如果是选了否定的选项，那么就照常打出crash log之类的。 这调试器接上去之后，再要做什么操作就看用户自己想怎样了。可以看stack trace、看内存之类的，也可以在调试器里做core dump之类。耗的时间取决于执行什么操作。 如果没有调试这种crash的JVM经验的话，我是建议不要打开这个参数的。 ===================================== JVM crash有很多可能性。如果确实跟JNI相关，那么打开-Xcheck:jni是可以提前发现一些错误。但你遇到的crash不一定是这种问题，所以开了有没有用无法笼统的说。应该先从crash log分析一下是什么类型的crash再说。 |
|
xiaoyu
2012-04-05
RednaxelaFX 写道 Oracle JDK / OpenJDK里，-XX:+ShowMessageBoxOnError 这个参数的主要作用是当一个Java进程crash的时候，在打出crash log之前先弹出“提示框”让用户有机会连接一个调试器到这个Java进程上，做现场调试。“提示框”不一定真的是图形界面的“框”，在Linux上的实现默认是字符界面的。
如果在提示框点了“确定”或输入“y”表示确认，那么接下来会自动启动调试器连接上了；如果是选了否定的选项，那么就照常打出crash log之类的。 这调试器接上去之后，再要做什么操作就看用户自己想怎样了。可以看stack trace、看内存之类的，也可以在调试器里做core dump之类。耗的时间取决于执行什么操作。 如果没有调试这种crash的JVM经验的话，我是建议不要打开这个参数的。 ===================================== JVM crash有很多可能性。如果确实跟JNI相关，那么打开-Xcheck:jni是可以提前发现一些错误。但你遇到的crash不一定是这种问题，所以开了有没有用无法笼统的说。应该先从crash log分析一下是什么类型的crash再说。 @RednaxelaFX : 先谢谢了. 1. 对于生产上配置了大内存的JVM(基本上不能用core dump了), 是否应该使用 -XX:+ShowMessageBoxOnError ? (是不是我要使用screen 方式启动程序了呢? 对于nohup就不行了, 是否还有其他方式呢?  )
2. 如果是C2 编译 Task 导致了JVM Crash的话, -Xcheck:jni 有帮助吗? (啥时候共享一下crash 调试的经验呀? )
|
|
RednaxelaFX
2012-04-05
1. 其实我是建议不要开这个参数，它多半会给你带来更长的暂停时间。
你的Java应用的VIRT大概有多少？我这边VIRT在7GB的都照样让它做core dump。你的顾虑是什么？ 2、没有。 |
|
xiaoyu
2012-04-05
RednaxelaFX 写道 1. 其实我是建议不要开这个参数，它多半会给你带来更长的暂停时间。
你的Java应用的VIRT大概有多少？我这边VIRT在7GB的都照样让它做core dump。你的顾虑是什么？ 2、没有。 我是使用了一下3G左右的堆, 生产core dump竟然要暂停7分钟(测试环境做的测试)..而且还消耗cpu, io. 所以有点担心. (VIRT大概是2.7G) 虽然 -XX:+ShowMessageBoxOnError 会暂停很久, 但是至少不会影响其他应用(就是说不会消耗cpu, io等). 谢谢了. |
|
RednaxelaFX
2012-04-05
如果你真的很担心core dump造成的开销的话，直接在起你的Java应用的那个shell session里配置ulimit -c 0就完事了，core dump就不会打出来了。不需要用ShowMessageBoxOnError这么绕弯的办法。
|
|
xiaoyu
2012-04-06
RednaxelaFX 写道 如果你真的很担心core dump造成的开销的话，直接在起你的Java应用的那个shell session里配置ulimit -c 0就完事了，core dump就不会打出来了。不需要用ShowMessageBoxOnError这么绕弯的办法。
我的目的是core dump不出来, 但是还能调试(其实本来就是ulimit -c 0的...). 主要是有点特别,一个机器上有多个应用(都是共享cpu和内存,IO的). 我说要加上core dump, 他们不肯(他们宁愿放弃找问题). 所以我只好另寻一条路.. 但是如果ShowMessageBoxOnError只能使用screen启动方式的话. 估计又是一个麻烦事. 哎.... |
|
xiaoyu
2012-04-06
一般的JVM Crash 都还好. 可以根据日志文件到.so里面去找到那个方法, 然后到jvm bug list 找到是否有相关的bug(一般都有..)
就是担心没有找到bug. 那就悲催了.然后重现问题也是很麻烦... |
|
RednaxelaFX
2012-04-06
原来有这么悲催的限制条件…嗯我只能说good luck了
如果你的进程平时完全不用stdin的话，可以在启动的时候重定向一个文件到stdin，这文件的内容就是y加换行符…或许可以？ |
|
xiaoyu
2012-04-09
RednaxelaFX 写道 原来有这么悲催的限制条件…嗯我只能说good luck了
如果你的进程平时完全不用stdin的话，可以在启动的时候重定向一个文件到stdin，这文件的内容就是y加换行符…或许可以？ 呵呵. 好办法. 应该是可以的. 谢谢了. |
